On Sat, May 02, 2015 at 09:27:49AM -0700, Linus Torvalds wrote:
> On Sat, May 2, 2015 at 1:30 AM, NeilBrown <neilb@xxxxxxx> wrote:
> >
> > All the calls in md.c are in a kernel thread so safe, but I'd rather have an
> > explicit "uninterruptible, but no load-average" wait....
>
> Hmm. Our task state is a bitmask anyway, so we could probably just add a
>
> #define __TASK_NOLOAD 16
>
> (and move the EXIT_xyz defines *away* from the list that is actually
> the task state), and teach our load average thing to not count those
> kinds of waits. Then you could just use
>
> TASK_UNINTERRUPTIBLE | __TASK_NOLOAD
>
> to make processes not count towards the load.
>
> Or - probably preferably - we could really clean things up, and make
> things much more like the bitmask it *should* be, and have explicit
> bits for
>
> - SLEEPING/STOPPED/EXITING ("why not running?")
> - LOADAVG (accounted towards load)
> - WAKESIG (ie "interruptible")
> - WAKEKILL (this we already have)
>
> and just make the rule be that we use "__TASK_xyz" for the actual
> individual bits, and "TASK_xyz" for the helper combinations. So then
> we'd have
>
> #define TASK_UNINTERRUPTIBLE (__TASK_SLEEPING | __TASK_LOADAVG)
> #define TASK_INTERRUPTIBLE (__TASK_SLEEPING | __TASK_WAKESIG)
> #define TASK_KILLABLE (__TASK_SLEEPING | __TASK_WAKEKILL)
> #define TASK_NOLOADAVG (__TASK_SLEEPING)
>
> which is almost certainly how this *should* have been done, but isn't,
> because of historical use.
>
> Cleaning up like that *should* be fairly simple, but I'd be a bit
> nervous about getting all the state comparisons right (we have an
> unholy mix of "check this bit" and "check this whole state", and we'd
> need to make sure we get those cases all right).
>
> Ingo, what do you think? This is mostly a scheduler interface issue..
Hehe, a little something like this:
https://lkml.org/lkml/2013/11/12/710
Lemme go clean that up and finish it :-)
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
