Messages in this thread | | | Subject | Re: [RFC][PATCH 02/22] sched: add extended scheduling interface | From | Peter Zijlstra <> | Date | Thu, 11 Nov 2010 15:08:51 +0100 |
| |
On Thu, 2010-11-11 at 14:54 +0100, Raistlin wrote: > > The last three parameters look to be output only as I've not yet found > > code that reads it, and __getparam_dl() doesn't even appear to set > > used_runtime. > > > Yeah, just kind of statistical reporting of the task's behaviour. That's > why I was in agreement with Dhaval about using schedstats for those > (bumping the version, obviously). What do you think?
So its pure output? In that case its not really a nice fit for sched_param, however..
I'm not really a fan of schedstat, esp if you have to use it very frequently, the overhead of open()+read()+close() + parsing text is quite high.
Then again, if people are really going to use this (big if I guess) we could add yet another syscall for this or whatever.
> > One thing you can do is add some padding, versioning and void* > > extentions are doable for the setparam() path, but getparam() is going > > to be mighty interesting. > > > Mmm... So, tell me if I got it well: I remove the last three parameters > (e.g., moving them toward schedstats) and add (besides _var and _max) > some padding? It that correct?
grmbl, so I was going to say, just pad it to a nice 2^n size, but then I saw that struct timespec is defined as two long's, which means we're going to have to do compat crap.
Thomas is there a sane time format in existence? I thought the whole purpose of timeval/timespec was to avoid having to use a u64, but then using longs as opposed to int totally defeats the purpose.
> what about the len <== sizeof(struct sched_param2) in > sched_{set,get}{param,scheduler}2()... Does this still make sense, or > are we removing it?
Since we're going for a constant sized structure we might as well take it out.
| |