Re: [RFC][PATCH 1/7] Resource counters

On Tue, Mar 13, 2007 at 06:41:05PM +0300, Pavel Emelianov wrote:
PS: atomic_add_unless() didn't exist back then
(at least I think so) but that might be an option
too ...
I think as far as having this discussion if you can remove that race
people will be more willing to talk about what vserver does.

well, shouldn't be a big deal to brush that patch up
(if somebody actually _is_ interested)

That said anything that uses locks or atomic operations (finer grained
locks) because of the cache line ping pong is going to have scaling
issues on large boxes.

right, but atomic ops have much less impact on most
architectures than locks :)

Right. But atomic_add_unless() is slower as it is
essentially a loop. See my previous letter in this sub-thread.

fine, nobody actually uses atomic_add_unless(), or am I
missing something?

using two locks will be slower than using a single
lock, adding a loop which counts from 0 to 100 will
eat up some cpu, so what? don't do it :)

So in that sense anything short of per cpu variables sucks at scale.
That said I would much rather get a simple correct version without the
complexity of per cpu counters, before we optimize the counters that
much.

actually I thought about per cpu counters quite a lot, and
we (Llinux-VServer) use them for accounting, but please
tell me how you use per cpu structures for implementing
limits

Did you ever look at how get_empty_filp() works?
I agree, that this is not a "strict" limit, but it
limits the usage wit some "precision".

/* off-the-topic */ Herbert, you've lost Balbir again:
In this sub-thread some letters up Eric wrote a letter with
Balbir in Cc:. The next reply from you doesn't include him.

I can happily add him to every email I reply to, but he
definitely isn't removed by my mailer (as I already stated,
it might be the mailing list which does this), fact is, the
email arrives here without him in the cc, so a reply does
not contain it either ...

best,
Herbert

-
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/

Relevant Pages

  • Re: [RFC][PATCH 1/7] Resource counters
    ... locks) because of the cache line ping pong is going to have scaling ... See my previous letter in this sub-thread. ... complexity of per cpu counters, before we optimize the counters that ... limits the usage wit some "precision". ...
    (Linux-Kernel)
  • Re: [patch] lockf(3) user-exploitable kernel panic
    ... > count the number of advisory-mode locks held by a process (I didn't need ... that those programs often use single letters for the rlimits. ... > kernel memory a user can have or any other limits which would disallow ... The sysctland sysctlmanpages haven't been updated, ...
    (freebsd-arch)
  • Re: [patch] lockf(3) user-exploitable kernel panic
    ... > shell stuff is really secondary. ... login.conf limits are already taken care of; so are libutil, limit, ... number of flock-style locks as well. ...
    (freebsd-arch)