Process & threads - Karmic vs past kernels

Peter Matulis peter.matulis at canonical.com
Fri Mar 12 15:20:57 UTC 2010


Tim Gardner wrote:
> On 03/12/2010 07:17 AM, Peter Matulis wrote:
>> Chase Douglas wrote:
>>> On Wed, Mar 10, 2010 at 3:45 PM, Peter Matulis
>>> <peter.matulis at canonical.com>  wrote:
>>>> Can anyone tell me whether the Karmic kernel has implemented a
>>>> different
>>>> way of what it considers a process (as opposed to threads)?
>>>>
>>>> I have a situation where CPU load is zero on Karmic but considerably
>>>> higher in Jaunty and earlier.
>>>>
>>>> The scenario is a single java process with many threads.  The system
>>>> has
>>>> 4 cores and only one java process should logically produce a negligible
>>>> CPU load but why was this not the case with earlier kernels?  Has
>>>> something changed in Karmic that would explain what I'm seeing?
>>>
>>> I doubt that to be the case. Have you been able to get more data for
>>> your bug [1]?
>>>
>>> Thanks,
>>> Chase
>>>
>>> [1] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/513848
>>
>> Yes, but I couldn't get as much CPU usage out of the Karmic test.  My
>> 'top' results show the following:
>>
>> Cpu1  :  0.3%us,  0.6%sy
>> Cpu2  :  2.4%us,  0.6%sy
>> Cpu3  :  9.1%us,  1.8%sy
>> Cpu4  : 16.0%us,  7.4%sy
>>
>> With a load of 0.00 across the board.
>>
>> Now since CPU1 has such a low usage it makes sense that load is
>> negligible since that CPU is always available.  It seems that the
>> question is now:
>>
>> Why the CPU usage is so much different between Karmic and Jaunty in this
>>   (single process/multiple thread) scenario.
>>
> 
> There was a pretty major change in the process and I/O schedulers
> between Jaunty and Karmic. Lucid is different yet again.
> 

Thanks Tim.  Are you saying that the Karmic kernel is more efficient or
it's just a matter of how usage/load is reported (process/threads)?

Could you point me to the details concerning this change?

-- 
Peter Matulis         |   GPG 34F740E8
Ubuntu Support Team   |   Canonical Ltd. (canonical.com)




More information about the kernel-team mailing list