[PL #6643] Re: pl_mom reset slice unimelb_vote on planetlab2.cs.umd.edu

[Mark Huang via RT]

Email Recipients (see http://www.planet-lab.org/Support)
       Owner: mlhuang
       Requestor: aharwood at cs.mu.OZ.AU
       Ticket Ccs: pl-mom at planet-lab.org, unimelb_vote at slices.planet-lab.org

==================================================

> So pl_mom may need to identify processes that are actually java  
> threads and do appropriate accounting.

I've moved this ticket to the Devel queue.

As I understand things, the problem is not with pl_mom or
princeton_slicestat (where pl_mom gets its information), but with legacy
apps and libraries that have not been ported to use the new threading
support in the 2.6.x kernel, specifically the CLONE_THREAD flag. Do your
Java threads show up as separate processes using "top" or "ps"? If so,
then there's nothing princeton_slicestat or pl_mom can do to
appropriately account for them.

If not, I'm on the wrong track. From the procps FAQ:

-----

Why do ps and top show threads individually?

The 2.4.xx kernel does not provide proper support for grouping threads by 
process. Hacks exist to group them anyway, but such hacks will falsely
group 
similar tasks and will fail to group tasks due to race conditions. The
hacks 
are also slow. As none of this is acceptable in a critical system tool,
task 
grouping is not currently available for the 2.4.xx kernel. The 2.6.xx
kernel 
allows for proper thread grouping and reporting. To take advantage of this, 
your programs must use a threading library that features the
CLONE_THREAD flag.
The NPTL pthreads provided by recent glibc releases use CLONE_THREAD.