Thread (21 messages) flat view 21 messages, 3 authors, 2015-07-17

Re: [PATCH -mm v8 4/7] proc: add kpagecgroup file

From: Vladimir Davydov <hidden>
Date: 2015-07-17 09:28:06
Also in: cgroups, linux-mm, lkml

On Thu, Jul 16, 2015 at 12:04:59PM -0700, Andres Lagar-Cavilla wrote:
On Thu, Jul 16, 2015 at 2:28 AM, Vladimir Davydov [off-list ref]
wrote:
quoted
On Wed, Jul 15, 2015 at 12:03:18PM -0700, Andres Lagar-Cavilla wrote:
quoted
For both /proc/kpage* interfaces you add (and more critically for the
rmap-causing one, kpageidle):

It's a good idea to do cond_sched(). Whether after each pfn, each Nth
pfn, each put_user, I leave to you, but a reasonable cadence is
needed, because user-space can call this on the entire physical
address space, and that's a lot of work to do without re-scheduling.
I really don't think it's necessary. These files can only be
read/written by the root, who has plenty ways to kill the system anyway.
The program that is allowed to read/write these files must be conscious
and do it in batches of reasonable size. AFAICS the same reasoning
already lays behind /proc/kpagecount and /proc/kpageflag, which also do
not thrust the "right" batch size on their readers.
Beg to disagree. You're conflating intended use with system health. A
cond_sched() is a one-liner.
I would still prefer not to clutter the code with cond_resched's, but I
don't think it's a matter worth arguing upon, so I'll prepare a patch
that makes all /proc/kapge* files issue cond_resched periodically and
leave it up to Andrew to decide if it should be applied or not.

Thanks,
Vladimir
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help