lkml.org 
[lkml]   [2004]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] Minneapolis Cluster Summit, July 29-30
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.
>
>
>>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.
-
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:04    [W:0.143 / U:1.288 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site