Shared Memory

Go To Last Post
10 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'm using the sysvipc shm feature to share large arrays between processes. It seems that if I exceed 4096 bytes for a shared memory, I get an exception. I found in the kernel code that the page size was 4K. I'm guessing that a shared memory can't exceed the page size ???

In the kernel source file 'page.h' I changed the page size to 8192 and rebuild a kernel. It boots and runs through the init, but then just stops. No exception is thrown.

Has anyone had any experience using shm larger than 4K, or modifying a kernel to increase the page size? I'm sure I'll figure it out eventually, but any guidance or direction would be appreciated.

The kernel source I'm using is 2.6.23.atmel.5

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ronter wrote:
I'm using the sysvipc shm feature to share large arrays between processes. It seems that if I exceed 4096 bytes for a shared memory, I get an exception. I found in the kernel code that the page size was 4K. I'm guessing that a shared memory can't exceed the page size ???
Hmm, this might be a kernel bug as the shared memory size shouldn't be restricted. In fact, the share size always gets rounded up to the nearest multiple of PAGE_SIZE.
Quote:
In the kernel source file 'page.h' I changed the page size to 8192 and rebuild a kernel. It boots and runs through the init, but then just stops. No exception is thrown.
Oh god, don't go there. It takes much much more than just playing with PAGE_SIZE to get it to work.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
ronter wrote:
I'm using the sysvipc shm feature to share large arrays between processes. It seems that if I exceed 4096 bytes for a shared memory, I get an exception. I found in the kernel code that the page size was 4K. I'm guessing that a shared memory can't exceed the page size ???
Hmm, this might be a kernel bug as the shared memory size shouldn't be restricted. In fact, the share size always gets rounded up to the nearest multiple of PAGE_SIZE.
Quote:
In the kernel source file 'page.h' I changed the page size to 8192 and rebuild a kernel. It boots and runs through the init, but then just stops. No exception is thrown.
Oh god, don't go there. It takes much much more than just playing with PAGE_SIZE to get it to work.

-S.

Thanks squidgit; it makes sense that the shared memory would be an integral number of PAGE_SIZE even though the proc/sysvipc/shm shows the actual size allocated; not the rounded up value.

I don't think there's a kernel bug. I just wrote a separate test program to create a shared memory of whatever size I specified. It worked fine with over 4096 and even up to 8500 without throwing any segmentation faults. If there's any bugs, they're probably in my own code :oops:

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ah goodgood :-). G'luck nuking that one.

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Take a look at SHMALL, SHMMAX, and SHMMNI, and make sure they're set to reasonable values.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
Quote:
In the kernel source file 'page.h' I changed the page size to 8192 and rebuild a kernel. It boots and runs through the init, but then just stops. No exception is thrown.
Oh god, don't go there. It takes much much more than just playing with PAGE_SIZE to get it to work.

Indeed. It might work if you teach the TLB code to load two 4k pages at a time, but otherwise you'll just get crashes and generally mysterious behaviour. Might be a fun thing to experiment with, but I don't recommend it for the faint of heart.

It should definitely be possible to set up a shm segment larger than a page. I'd be surprised if it's a kernel bug since the SysV IPC calls are the same on most architectures.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

how wrote:
squidgit wrote:
Quote:
In the kernel source file 'page.h' I changed the page size to 8192 and rebuild a kernel. It boots and runs through the init, but then just stops. No exception is thrown.
Oh god, don't go there. It takes much much more than just playing with PAGE_SIZE to get it to work.

Indeed. It might work if you teach the TLB code to load two 4k pages at a time, but otherwise you'll just get crashes and generally mysterious behaviour. Might be a fun thing to experiment with, but I don't recommend it for the faint of heart.

It should definitely be possible to set up a shm segment larger than a page. I'd be surprised if it's a kernel bug since the SysV IPC calls are the same on most architectures.

Silly me - thinking that linux code would actually conform to the most basic of good programming principles.. that is by changing a single #define, all code should fall into place, or at the very least a compiler error be generated when a discrepancy is detected :roll:

In this particular case, I think I must be clobbering an index somewhere that puts me out of bounds in one of the shared memory arrays. My new test program proved that there was no problem creating shms of any size. I even did read/writes to every location in the shm without any segment fault crashes.

Another question if I may...

I have a JTAG MKII but haven't figured out a way to debug an application program running under AVR2 linux. Is this even possible? If so, where would I need to read about how this is done? At present I can only test the basic functionality of a program by running it under debugger in Fedora.

Thanks.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ronter wrote:
Silly me - thinking that linux code would actually conform to the most basic of good programming principles.. that is by changing a single #define, all code should fall into place, or at the very least a compiler error be generated when a discrepancy is detected :roll:
Um, PAGE_SIZE is governed to a great extent by hardware. It'd be a sweet compiler indeed which could reorganize gates in my CPU given a #define ;-)

I 'spose the comment could be a bit scarier but I don't think that many people are expected to go poking semi-randomly at kernel internals and expecting it to work after :-)

Quote:
I have a JTAG MKII but haven't figured out a way to debug an application program running under AVR2 linux. Is this even possible? If so, where would I need to read about how this is done? At present I can only test the basic functionality of a program by running it under debugger in Fedora.
You can run it under gdb on the target and have the debug information forwarded over the network to a gdb client on your PC. See the bottom of https://www.avrfreaks.net/wiki/in... :-)

-S.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

squidgit wrote:
ronter wrote:
Silly me - thinking that linux code would actually conform to the most basic of good programming principles.. that is by changing a single #define, all code should fall into place, or at the very least a compiler error be generated when a discrepancy is detected :roll:
Um, PAGE_SIZE is governed to a great extent by hardware. It'd be a sweet compiler indeed which could reorganize gates in my CPU given a #define ;-)

I 'spose the comment could be a bit scarier but I don't think that many people are expected to go poking semi-randomly at kernel internals and expecting it to work after :-)

Quote:
I have a JTAG MKII but haven't figured out a way to debug an application program running under AVR2 linux. Is this even possible? If so, where would I need to read about how this is done? At present I can only test the basic functionality of a program by running it under debugger in Fedora.
You can run it under gdb on the target and have the debug information forwarded over the network to a gdb client on your PC. See the bottom of https://www.avrfreaks.net/wiki/in... :-)

-S.

Thank you once again squidgit. I'll try to load a gdbserver onto the NGW100 and see how that goes. Debugging with printfs has its limitations.

Sometimes I get frustrated with the whole process of working with Linux. I have been a software developer since about 1967 and have worked on many hardware platforms and operating systems. By some cruel trick of fate, I managed to avoid Unix and most of its variants except QNX and VAX Unix. In those cases, the O/S came completely documented and fully supported by the vendor. Venturing into the source code was not an option.

I have written my own micro-kernels for several processors like 68K and Z80 ( yeah, I'm that old :lol: ). Generally before working on a new CPU I try to learn everything I can about the processor architecture. I may even build a board to get familiar with the interfaces. In the case of the NGW100 with AVR32-Linux I had a specific home security application in mind and treated it much like I treat the PC - where you need to care very little about the CPU architecture or O/S internals to produce applications. It didn't take me long to discover the flaw in that approach. The posts on this forum have been invaluable in figuring out things like how to implement additional UARTs and RS485.

On many commercial development projects we have to submit our code for peer review. The types of things that are looked for are precisely what I mentioned about the PAGE_SIZE. For example, if you use '#define CLOCK 8000000' to identify the crystal, then any code which programs a hardware timer or baud rate generator should use a value derived from the 'CLOCK' symbol, not just assume it to be 8Mhz. Change the 'CLOCK' defined value and everything else falls into place nicely without needing to search through all the code. I know that can't work in every case, but it's something to strive for.

I totally understand that the Linux kernel is complex and has been ported over a zillion different platforms. That is no small feat! Along the way, I think clarity was sacrificed for flexibility. A lot of deprecated legacy code got left behind for the uninitiated to stumble over. You really have to grasp the whole picture to truly know what's going on. I feel like I'm exploring a gigantic cavern with a candle; only seeing little pieces at a time.

I really appreciate that folks here are so knowledgeable on the Linux internals and are willing to help the rest of us that are trying to slog our way through it.

Sorry for the long winded rant, but I didn't want anyone to think I was knocking down Linux just for troll bait.

Thanks again.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ronter wrote:
Thank you once again squidgit. I'll try to load a gdbserver onto the NGW100 and see how that goes. Debugging with printfs has its limitations.
np, quite right
ronter wrote:
... In the case of the NGW100 with AVR32-Linux I had a specific home security application in mind and treated it much like I treat the PC - where you need to care very little about the CPU architecture or O/S internals to produce applications. It didn't take me long to discover the flaw in that approach. The posts on this forum have been invaluable in figuring out things like how to implement additional UARTs and RS485.
Well you can treat it exactly like your PC, where RS485 isn't supported at all by hardware and to add usarts you add more hardware to the bus then make sure it gets probed. The things you describe are examples of getting access to features your PC just doesn't have, and yes indeed that means you can't treat it as a regular PC.

That said, I completely agree that the process of having to dig in to kernel internals just to alter the peripherals policy someone else has done for you is a pain. A few of us are currently looking in to implementing fdt for the AVR32 (currently only PPC uses it). This would mean that all hardware description is done in an english-like (or at least human-readable) description file, compiled to a binary and passed to the kernel by the bootloader. Then any change to any hardware would take a tweak of a config file and a reboot, something I'm sure most of us are happy with! It's a little way off yet though :-)

Quote:
On many commercial development projects we have to submit our code for peer review. The types of things that are looked for are precisely what I mentioned about the PAGE_SIZE. For example, if you use '#define CLOCK 8000000' to identify the crystal, then any code which programs a hardware timer or baud rate generator should use a value derived from the 'CLOCK' symbol, not just assume it to be 8Mhz. Change the 'CLOCK' defined value and everything else falls into place nicely without needing to search through all the code. I know that can't work in every case, but it's something to strive for.
No doubt at all and it is achievable in 99% of cases. One case where it isn't possible is when it has to match an external constraint like, eg, physical page size. In this case sure it prolly should be more fully commented, trufax, but then there's precious little of the Linux Kernel which doesn't have a (sometimes hidden) learning curve :-)
ronter wrote:
I totally understand that the Linux kernel is complex and has been ported over a zillion different platforms. That is no small feat! Along the way, I think clarity was sacrificed for flexibility.
I think most of the time they've actually done a fantastic job in actually using the flexibility to _increase_ clarity. Certainly in recent times at least. Sure, Linux 0.1 is probably clearer but less flexible than 2.6.27 but then 2.6.27 is clearer _and_ more flexible than a lot of the 2.4 series. It ain't perfect, but it's getting there.
ronter wrote:
A lot of deprecated legacy code got left behind for the uninitiated to stumble over.
Very true, luckily most of it though is mainly in legacy archs like x86. Certainly I'm very glad a lot of the time I'm hacking on AVR32.
ronter wrote:
You really have to grasp the whole picture to truly know what's going on. I feel like I'm exploring a gigantic cavern with a candle; only seeing little pieces at a time.
Now that's the big big thing. Often the clarity is there, just one layer further out than you're currently looking. Cavern with a candle is a good analogy, another might viewing the Sistine Chapel through a mailbox. It's beautiful, clear and well laid out if you can see the whole thing (or substantial portions) but if you're only examining a little slot then you're certainly not going to get it.
ronter wrote:
I really appreciate that folks here are so knowledgeable on the Linux internals and are willing to help the rest of us that are trying to slog our way through it.

Sorry for the long winded rant, but I didn't want anyone to think I was knocking down Linux just for troll bait.

np, good points :-)

-S.