Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
On Wed, Jan 27, 2010 at 05:26:25PM -0600, John B Moore wrote: This bug has been found and fixed. The issue was a missing SetPageDirty in ramfs_nommu_expand_for_mapping in fs/ramfs/file-nommu.c. This allowed the ramfs shared memory storage to be considered for being freed from the pagecache in shrink_active_list . This problem appears to have been fixed in later releases in the ramfs driver since the newer driver already has the SetPageDirty call added, but just in case someone else runs into this What's the patch actually ? Philippe ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
This bug has been found and fixed. The issue was a missing SetPageDirty in ramfs_nommu_expand_for_mapping in fs/ramfs/file-nommu.c. This allowed the ramfs shared memory storage to be considered for being freed from the pagecache in shrink_active_list . This problem appears to have been fixed in later releases in the ramfs driver since the newer driver already has the SetPageDirty call added, but just in case someone else runs into this issue on these older releases, I thought I would document the fix. John Moore John B Moore jmo...@moreycorp.com Sent by: uclinux-dev-boun...@uclinux.org 01/22/2010 05:46 PM Please respond to uClinux development list uclinux-dev@uclinux.org To uClinux development list uclinux-dev@uclinux.org cc Subject Re: [uClinux-dev] Disk Cache overlaying Shared Memory? After looking even deeper, it appears as though the shared memory page is getting properly marked as being mmapped when the shmat is called , but when shrink_active_list is called to clean up the pagecache in vmscan.c, the mmapped page still ends up getting freed. In shrink_active_list, it gets all the way to calling remove_mapping on that block of storage even though page_mapping_inuse shows the page is in use. However, page_referenced shows that there are 0 or -1 references even though there is actually 1 reference in the running application. Since the reference count on the nommu platforms is derived from a test_and_clear_bit on page-flags bit 2 (via page_referenced macro in rmap) this would assume that something is changing that referenced bit when the page is still being referenced. I'll keep looking, but any ideas why the referenced bit in the page-flags could changing are appreciated. John Moore Jamie Lokier ja...@shareable.org Sent by: uclinux-dev-boun...@uclinux.org 01/22/2010 05:21 AM Please respond to uClinux development list uclinux-dev@uclinux.org To uClinux development list uclinux-dev@uclinux.org cc Subject Re: [uClinux-dev] Disk Cache overlaying Shared Memory? John B Moore wrote: After more detail examination of this problem, what I see is that the storage for the shared memory appears to be allocated via RAMFS in the pagecache in tiny-shmem.c (i.e. a non-mmu platform) and the storage is mmapped when the shmat is performed. When the pagecache hits its threshold of low RAM and starts to cleanup, the mmapped storage for the shared memory segment gets cleaned up as well old file cache entries. Eventually this storage gets re-used as pagecache and makes it appear as though the JFFS2 file system has overwritten the shared memory block when in reality the storage was freed and re-used. From looking at the code, either the page is not getting properly flagged as being mmapped on shmat or I am missing something in the pagecache cleanup code since it appears that any mmapped storage in the pagecache will always be ignored during cleanup. If that's what's happening it'd be quite a serious bug, although SYSV SHM isn't used much on NOMMU so it could have been missed. Do you know if it does the same thing when using POSIX shared memory (if that even works)? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent
Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
After looking even deeper, it appears as though the shared memory page is getting properly marked as being mmapped when the shmat is called , but when shrink_active_list is called to clean up the pagecache in vmscan.c, the mmapped page still ends up getting freed. In shrink_active_list, it gets all the way to calling remove_mapping on that block of storage even though page_mapping_inuse shows the page is in use. However, page_referenced shows that there are 0 or -1 references even though there is actually 1 reference in the running application. Since the reference count on the nommu platforms is derived from a test_and_clear_bit on page-flags bit 2 (via page_referenced macro in rmap) this would assume that something is changing that referenced bit when the page is still being referenced. I'll keep looking, but any ideas why the referenced bit in the page-flags could changing are appreciated. John Moore Jamie Lokier ja...@shareable.org Sent by: uclinux-dev-boun...@uclinux.org 01/22/2010 05:21 AM Please respond to uClinux development list uclinux-dev@uclinux.org To uClinux development list uclinux-dev@uclinux.org cc Subject Re: [uClinux-dev] Disk Cache overlaying Shared Memory? John B Moore wrote: After more detail examination of this problem, what I see is that the storage for the shared memory appears to be allocated via RAMFS in the pagecache in tiny-shmem.c (i.e. a non-mmu platform) and the storage is mmapped when the shmat is performed. When the pagecache hits its threshold of low RAM and starts to cleanup, the mmapped storage for the shared memory segment gets cleaned up as well old file cache entries. Eventually this storage gets re-used as pagecache and makes it appear as though the JFFS2 file system has overwritten the shared memory block when in reality the storage was freed and re-used. From looking at the code, either the page is not getting properly flagged as being mmapped on shmat or I am missing something in the pagecache cleanup code since it appears that any mmapped storage in the pagecache will always be ignored during cleanup. If that's what's happening it'd be quite a serious bug, although SYSV SHM isn't used much on NOMMU so it could have been missed. Do you know if it does the same thing when using POSIX shared memory (if that even works)? -- Jamie ___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
Re: [uClinux-dev] Disk Cache overlaying Shared Memory?
After more detail examination of this problem, what I see is that the storage for the shared memory appears to be allocated via RAMFS in the pagecache in tiny-shmem.c (i.e. a non-mmu platform) and the storage is mmapped when the shmat is performed. When the pagecache hits its threshold of low RAM and starts to cleanup, the mmapped storage for the shared memory segment gets cleaned up as well old file cache entries. Eventually this storage gets re-used as pagecache and makes it appear as though the JFFS2 file system has overwritten the shared memory block when in reality the storage was freed and re-used. From looking at the code, either the page is not getting properly flagged as being mmapped on shmat or I am missing something in the pagecache cleanup code since it appears that any mmapped storage in the pagecache will always be ignored during cleanup. Any ideas? John Moore John B Moore jmo...@moreycorp.com Sent by: uclinux-dev-boun...@uclinux.org 01/20/2010 03:49 PM Please respond to uClinux development list uclinux-dev@uclinux.org To uClinux development list uclinux-dev@uclinux.org cc Subject [uClinux-dev] Disk Cache overlaying Shared Memory? I am running a 2.6.17 uClinux kernel on a Coldfire 5233 and am having an issue where it appears as though the disk cache is overlaying shared memory. In the application, I have allocated a 4K block of shared memory and am writing files to a JFFS2 file system. The Cached data size continues to grow as I continue to write files until about 1M of RAM is still available at which point the shared memory block gets overwritten with part of the data that was just written to JFFS2. This happens consistently and is easily reproducible. If I am not using shared memory but just malloc a block of storage instead, no overlay happens and the cache grows only slightly larger before it levels off as the cache cleans itself up. Any ideas why this overlay may be happening? John Moore This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev This e-mail, including attachments, may contain information that is confidential and/or proprietary, and may only be used by the person to whom this email is addressed. If the recipient of this e-mail is not the intended recipient or an authorized agent, the reader is hereby notified that any dissemination, distribution, or copying of this e-mail is prohibited. If this e-mail has been delivered to you in error, please notify the sender by replying to this message and deleting this e-mail immediately.___ uClinux-dev mailing list uClinux-dev@uclinux.org http://mailman.uclinux.org/mailman/listinfo/uclinux-dev This message was resent by uclinux-dev@uclinux.org To unsubscribe see: http://mailman.uclinux.org/mailman/options/uclinux-dev
