Re: objrmap and vmtruncate

[William Lee Irwin III]

On Tue, Apr 22, 2003 at 11:07:32AM -0400, Ingo Molnar wrote:
> also, it's an inherent DoS thing. Any application that has the 'privilege'
> of creating 1000 mappings in 1000 processes to the same inode (this is
> already being done, and it will be commonplace in a few years) will
> immediately DoS the whole VM. I might be repeating myself, but quadratic
> algorithms do get linearly _worse_ as the hw evolves. The pidhash
> quadratic behavior triggering the NMI watchdog on the biggest boxes is
> just one example of this.

I have to apologize for my misstatements of the problem here. You
yourself pointed out to me the hold time was, in fact, linear. Despite
the linearity of the algorithm, the failure mode persists. I've
postponed further investigation until later, when more invasive
techniques are admissible; /proc/ alone will not suffice if linear
algorithms under tasklist_lock can trigger this failure mode.

I believe further work is needed but I can't think of a 2.5.x mergeable
method to address it. I've attempted to devolve the work to others in
the hopes that future solutions might be devised. It's unfortunate but
general algorithmic scalability for scenarios like this has a real cost
for the low-end and it's a problem I don't feel comfortable trying to
fix in the middle of 2.5.x stabilization for more general systems.

Unless a refinement of either manfred's or your patches can be made to
pass the test (apologies again; I don't recall the results, my time on
the whole system is very limited and it was a while ago) I suspect very
little can be done for 2.5.x here. IMHO a series of patches to
eliminate all remaining linear scans under tasklist_lock alongside a
fair locking construct will be eventually required, though, of course,
only a solution is required, not my expectation.

-- wli