lkml.org 
[lkml]   [2004]   [Nov]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] [Request for inclusion] Filesystem in Userspace
From
Date

> 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/

\
 
 \ /
  Last update: 2005-03-22 14:08    [W:0.118 / U:0.108 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site