Re: /proc/data information

!MAILaRCHIVE_VOTE_RePLACE
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: <linux-kernel@...>
Date: Monday, July 14, 2008 - 3:47 pm

Andi Kleen wrote:

How can it always sample regularly like that? The only way I can think
of accounting is doing so in an event-based manner. That is, when a
process is given to a CPU you start counting, when you remove it you
stop the counter, that would be your CPU user time, then you'd start
counting for the system. Accounting for IO time and other CPU times
would happen in the same manner.

Now, I took a look at ``void scheduler_tick(void)'' (from sched.c). I
think it's the function that gets called in a timely manner. All I can
see it doing regarding clock is updating its value. It doesn't seem to
account for idle, user and system time.


I didn't think about the kernel disabling interrupts. But I'm not sure
that's the main issue in my experimentation, after all, that would make
me get smaller values rather than big values, no? I mean, on a idle
system each second has 100 samples, what I observed was that sometimes I
get as much as 500 samples in one second. If disabling interrupts was
the issue I think that I'd see values much smaller than 100.

I've noticed that the error doesn't change (thus becoming relatively
smaller) when I sleep for more time. So, looking at the samples each 10
seconds usually gives me 1000 samples, but it gets at 1500 at tops
(which is much better than getting 100 samples and reaching 500 at
tops). I wonder if maybe the error I'm seeing here has more to do with
the system not respecting the sleep time too well.


My interest here is on the x86 architeture, I don't suppose I can turn
on microstate accounting on it, can I?
--
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
/proc/data information, Rafael C. de Almeida, (Sun Jul 13, 4:07 pm)
Re: /proc/data information, Andi Kleen, (Mon Jul 14, 12:38 pm)
Re: /proc/data information, Rafael C. de Almeida, (Mon Jul 14, 3:47 pm)