Re: [ckrm-tech] PATCH: Re: Proposal for making ckrm_set_taskclass totally serial

[Hubertus F. <fr...@wa...>]

Chandra Seetharaman wrote:

> On Wed, Aug 25, 2004 at 05:21:41PM -0400, Hubertus Franke wrote:
> 
>>>The sticking point would be contention of the lock not necessarily the lock
>>>itself... the said single lock is held for a very short time(i.e time to
>>>update and check a variable).
>>
>>Ofcourse lock contention is what I was referring to. The other issue is 
> 
> 
> With my reasoning/code, do you agree there won't be contention ?
> 

shouldn't be ... agreed.

> 
>>that a single lock can become a hot cache line ...
> 
> 
> My thinking is that "hot cache" is an issue only if the "event" that
> moves the cache line around happens so very often, say like once/HZ or so. I
> don't think we will have that many classification events(only a handful of
> them over a task's life cycle).
> 

Yes, but now the lock is global and it is taken every classification 
event. So it will bounce across cpu's. In the kernel compile it was 
around 1/10msec.  Assuming 0x5400 events and 300 sec runtime.
Just something to keep in mind. Not a showstopper by any means.

> 
>>In the case where the lock is integrated the lock is likely already been
>>in the cache.
> 
> 
> This part is not clear to me.

Since the lock is located on the same cacheline as other CKRM related 
datastructures/pointes (i.e. within the struct task) it is basically in 
the cache, assuming that the cacheline has been touched.

> 
>>I'd say that looks quite reasonable ~97% within 1 msec.
>>Can you do the RTC stuff above to actually give "precise" numbers.
>>There's a difference between 999usecs and 2 usecs and it would be
>>nice to get this nailed down.
> 
> 
> Does it make much difference ? A task is classified properly within 1msec,
> I doubt we need classification happen faster than that.

I am concerned that the orders are properly handled. Since we are 
processing the reassignment asynchronously, can we guarantee that the 
reassignment has been executed, before we look at it again ?
If we can't, what is our policy wrt to this.

> 
> Anyways, just to make you happy I 'll do it. 
> 
> Now tell me how to get RTC ? (like I use "jiffies" for HZ)
> 

unsigned long long nansecs.

rdtscll(nansecs);

See arch/i386/kernel/timers/timer_tsc.c   @ sched_clock()..

> chandra
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> ckrm-tech mailing list
> https://lists.sourceforge.net/lists/listinfo/ckrm-tech
>