Messages in this thread | | | Subject | Re: [PATCH] [Request for inclusion] Filesystem in Userspace | From | Miklos Szeredi <> | Date | Sun, 21 Nov 2004 13:01:51 +0100 |
| |
> It already is. Your address space ->writepage can do > > redirty_page_for_writepage(wbc, page); > unlock_page(page); > return 0; > > And that is fine. NTFS does this. As does Reiserfs I believe.
As does fuse. Actually there might be a very limited number of pages in transit (10 per mount currently), but above that writepage will not attempt to send any more requests. I don't see what are the effects of these in-transit pages on the OOM killer triggering.
> For NTFS I do it exactly when I get to -ENOMEM so that I don't have enough > memory to coplete the writepage so I abort the write and redirty the page > so it gets tried again at a later time when more memory is freed. The > writeback control (wbc) ensures the VM doesn't just keep calling us trying > to clean the page to free it. It knows it is pointless so it gives up. > The OOM killer can then kill some other app which will free memory, and > then the writepage will be retried and it will succeed. Now I know > the fuse fs can be swapped out but why that would lead to a deadlock I > can't see. There always is something else to kill to free memory so the > fs can be swapped back in. And if the fs is killed surely all its pages > will be invalidated and thrown away by fuse, no?
They will.
Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |