Hello Haoqiang,

> I think it should be easy since reporting the additional numbers
> doesn't require any change to the core logic of the scheduler.

In what way do you suggest that I modify your scheduler to report
user/system time separately?

> It's charged to the current class.  Yes, it might be a cause of
> unfairness if interrupts consume significant amount of time.  But
> isn't it a tradtional thing that Linux does?

You are correct in noting that it is the conventional Unix approach, which
is precisely what I don't want.  Unless it is significantly difficult or
expensive to do so, I'd prefer to charge this time to a predefined system
class or simply the default /rcfs/taskclass class.

Marc

> -----Original Message-----
> From: Haoqiang Zheng [mailto:[EMAIL PROTECTED]
> Sent: Friday, January 28, 2005 9:43 PM
> To: Marc E. Fiuczynski
> Cc: ckrm-tech
> Subject: Re: [ckrm-tech] cpu scheduler feature request
>
>
> On Fri, 28 Jan 2005 13:36:59 -0500, Marc E. Fiuczynski
> <[EMAIL PROTECTED]> wrote:
> > Looking at a class' stats file, it appears that the CPU
> scheduler accounts
> > for all time spent on behalf of a class.  Would it be difficult
> to modify
> > the CPU scheduler to maintain stats on how much of that time is in user
> > space vs. kernel space?
>
> I think it should be easy since reporting the additional numbers
> doesn't require any change to the core logic of the scheduler.
>
> >
> > Also, when an interrupt is handled by the system, is that time
> charged to a
> > slice or to the system class?
> It's charged to the current class.  Yes, it might be a cause of
> unfairness if interrupts consume significant amount of time.  But
> isn't it a tradtional thing that Linux does?
>
> Haoqiang



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech

Reply via email to