Re: per-process shared information

[Andrea Arcangeli]

On Thu, Oct 14, 2004 at 10:49:28PM +0100, Hugh Dickins wrote:
> Is "shared" generally expected to pair with rss?  Would it make

shared is expected to work like in linux 2.4 (and apparently solaris),
which means _physical_ pages mapped in more than one task.

> Sounds horrid to me!  I'm not inclined to volunteer for that: plus this

what's horrid? would you add a O(log(N)) slowdown in the fast paths to
provide the stat in O(1)? I much prefer an O(N) loop in the stats as far
as it catches signals and reschedules as soon as need_resched is set.

if you can suggest a not-horrid approach to avoid breaking binary
compatibility to 2.4 you're welcome ;)

> One, support anon_rss as a subset of rss, "shared" being (rss - anon_rss).
> Yes, that's a slight change in meaning of "shared" from in 2.4, but easy
> to support and I think very reasonable.  On the one hand, yes, of course

that's certainly much better than what we have right now, it's much
closer to the old semantics, but I'm not sure if it's enough to be
compliant with the other OS (including 2.4). I will ask. 

I also guess the app will stop breaking since rss - shared will not wrap
anymore.

> we know an anon page may actually be shared between several mms of the
> fork group, whereas it won't be counted in "shared" with this patch. But
> the old definition of "shared" was considerably more stupid, wasn't it?
> for example, a private page in pte and swap cache got counted as shared.

just checking mapcount > 1 would do it right in 2.6.

> Would this new meaning of "shared" suit your purposes well enough?

It'd be fine for me, but I'm no the one how's having troubles.

> shouldn't change that now, but add your statm_phys_shared; whatever,

the only reason to add statm_phys_shared was to keep ps xav fast, if you
don't slowdown pa xav you can add another field at the end of statm.

Ideally shared should have been set to 0 and it should have been moved
to statm_phys_shared. It's slow but not so horrid thanks to the mapcount
which makes it really strightforward (it's just a vma + pgtable walk,
the only tricky bit is the signal catch and need_resched).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/