Re: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Thu, Jul 15, 2004 at 12:19:12PM +1000, Nick Piggin wrote:
> Pavel Machek wrote:
> >Hi!
> >
> >
> >>>I don't see why it would be a problem to implement a "this task
> >>>facilitates page reclaim" flag for userspace tasks that would take
> >>>care of this as well as the kernel does.
> >>
> >>Yes, that has been done before, and it works - userspace "block drivers"
> >>which permanently mark themselves as PF_MEMALLOC to avoid the obvious
> >>deadlocks.

Andrew, as curiosity, what userspace "block driver" sets PF_MEMALLOC for
normal operation?

> >>Note that you can achieve a similar thing in current 2.6 by acquiring
> >>realtime scheduling policy, but that's an artifact of some brainwave which
> >>a VM hacker happened to have and isn't a thing which should be relied 
> >>upon.
> >>
> >>A privileged syscall which allows a task to mark itself as one which
> >>cleans memory would make sense.
> >
> >
> >Does it work?
> >
> >I mean, in kernel, we have some memory cleaners (say 5), and they
> >need, say, 1MB total reserved memory.
> >
> >Now, if you add another task with PF_MEMALLOC. But now you'd need
> >1.2MB reserved memory, and you only have 1MB. Things are obviously
> >going to break at some point.
> >								Pavel
> 
> Well you'd have to be more careful than that. In particular
> you wouldn't just be starting these things up, let alone
> have them allocate 1MB in to free some memory.
> 
> This situation would still blow up whether you did it in
> kernel or not.

Indeed, such PF_MEMALLOC app can probably kill the system if it bugs
allocating lots of memory from the lower reservations. It needs
some limitation.