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

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.

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.
-
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 ... complexity of per cpu counters, before we optimize the counters that ... limits the usage wit some "precision". ... email arrives here without him in the cc, ...
    (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)