>Right now 2.3.7-1 (aka "dangerous") is not stable even with ext2, in that
>swapping doesn't work. Ingo just sent me patches to fix that, and I'm
If I understood well the code there are other problems that may cause FS
corruption. For example we must not allow a buffer shared with the page
cache to be placed in the free list. To do that I added a BH_Shared
bitflag and I check if the buffer is shared in set_blocksize(), in
invalidate_buffers (here), and in bforget.
Then at least with my VM/buffer/swap code I had a problem in
rw_swap_nocache that was forgetting to flushpage, now I am doing:
/*
* Setting up a new swap file needs a simple wrapper just to read the
* swap signature. SysV shared memory also needs a simple wrapper.
*/
void rw_swap_page_nocache(int rw, unsigned long entry, struct page * page)
{
lock_page(page);
rw_swap_page(rw, entry, page, 1);
lock_page(page);
generic_block_flushpage(NULL, page, 1);
UnlockPage(page);
}
remove_inode_page was not releasing the cache (while
delete_from_swap_cache was doing that by hand).
Then there is a big mess in generating dirty data. Flushtime is never
set and we are not starting bdflush if there is too much data dirty.
Then flushpage may start all the I/O before going to sleep, it may be far
more smart simply starting I/O for _all_ dirty buffers and then going to
wait for I/O completation. It should also be able to tell "there's IO in
progress so try again leather to free this page page" instead of waiting
in sync mode as now. Due this sync IO "feature" now `cp /dev/zero /tmp'
seems to work simply because we are less good in syncing data back to disk
and bdflush isn't working properly.
Now with my VM on UP (with SMP kernel) swapping seems to work fine, while
in real SMP I still have problems I think due my shrink_mmap that here is
SMP threaded in respect of the VM and of the big kernel lock. Now I'll
continue to fix this SMP issue. Hope to have a stable pagemap-lru-VM
against pre-2.3.7-1 very soon.
Andrea Arcangeli
Disclaimer: I am still in learning-mode so maybe I am missing something
about the above. Comments would be appreciated :).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/