On Fri, Apr 07, 2000 at 11:10:54PM +0200, almesber@lrc.di.epfl.ch wrote:
> > - when you open the device, the driver allocates some memory and
> > copies all the data from /proc atomically;
>
> This is slow. You may have to force out user pages and shrink caches
> to allocate all this. Also, it may be good to avoid holding
> tasklist_lock during all this (for latency).
This is true but unavoidable if you want atomic ps. Whether atomic ps
is useful or worth the cost is another issue entirely :).
[snip global_gen_num scheme]
> This creates an inconsistency if a parent ensures that all its children
> are dead before it terminates itself. You can avoid this by re-reading
> procsnap and removing all orphaned children that you don't see anymore
> in the second round.
Re-reading is unlikely to buy you much since the bad thing may happen
on the last read. Re-reading until it looks consistent might take many
tries.
> There is still a create-death race if a process is guaranteed to exist
> before another one dies, but this is probably a quite exotic scenario.
> (There may be more potential inconsistencies of this type.) Correctly
> solving this requires to defer process death.
Yup. I'd like not to alter default behaviour, though. No impact on
normal kernel code means that this has a bigger chance to go past
Linus, and if it doesn't, it can still work as a simple module
distributed separately.
> BTW, another issue is structure independence: exposing the plain task
> structure to user space is undesirable (version conflicts). You can
> either define your own "stable" structure and copy/convert the
> corresponding fields,
That's what I'm doing, with a reasonable way to provide for future
extensions (see the rest of this thread).
Wishes,
Borislav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:11 EST