Re: [PATCH] [Request for inclusion] Filesystem in Userspace

[Miklos Szeredi]

> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/