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

> you're describing the deadlock here: all memory is full, no process
> which allocates memory can make any progress.

Yes they, can: the allocation will fail, function will return -ENOMEM,
malloc will return NULL, pagefault will fail with OOM. This is
progress, though not the best sort. It is most certainly _not_ a
deadlock.

> This is not a true oom situation: there can be plenty of memory in
> dirty pagecache which we could reclaim if we had that tiny bit of
> reserve memory.

The amount of reserved memory that would be needed depends upon the
filesystem. Some filesystems would need only very little to be able
to free some memory, some would need a lot (e.g. a bzip2 compressing
filesystem). There's no magic solution with reserving memory.

And this is not unique to userspace filesystems, as Rik van Riel
pointed out earlier, network filesystems are also prone to deadlock:

http://lkml.org/lkml/2004/11/27/81

> >I looked at ramfs, it isn't even limited. You can easily crash your
> >system just by filling it up with data, but no deadlock will happen.
> >
> >
> Right. But ramfs doesn't call a userspace process which calls the kernel
> right back.

Doesn't matter one little whit. The end result is the same: Out Of
Memory, which is _not_ equivalent to deadlock. Please think it over.

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.096 / U:0.264 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site