linux-kernel - Re: [RFC -v2 PATCH 2/3] sched: add yield

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1292835302.8948.35.camel@marge.simson.net>
Date:	Mon, 20 Dec 2010 09:55:02 +0100
From:	Mike Galbraith <efault@....de>
To:	Avi Kivity <avi@...hat.com>
Cc:	Rik van Riel <riel@...hat.com>, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Chris Wright <chrisw@...s-sol.org>
Subject: Re: [RFC -v2 PATCH 2/3] sched: add yield_to function

On Mon, 2010-12-20 at 10:45 +0200, Avi Kivity wrote:
> On 12/20/2010 10:39 AM, Mike Galbraith wrote:
> > On Sun, 2010-12-19 at 11:19 +0200, Avi Kivity wrote:
> > >  On 12/19/2010 12:05 PM, Mike Galbraith wrote:
> >
> > >  >  >   We definitely want to maintain fairness.  Both with a dedicated virt
> > >  >  >   host and with a mixed workload.
> > >  >
> > >  >  That makes it difficult to the point of impossible.
> > >  >
> > >  >  You want a specific task to run NOW for good reasons, but any number of
> > >  >  tasks may want the same godlike power for equally good reasons.
> > >
> > >  I don't want it to run now.  I want it to run before some other task.  I
> > >  don't care if N other tasks run before both.  So no godlike powers
> > >  needed, simply a courteous "after you".
> >
> > Ponders that...
> >
> > What if: we test that both tasks are in the same thread group, if so,
> 
> In my use case, both tasks are in the same thread group, so that works.  
> I don't see why the requirement is needed though.

Because preempting a perfect stranger is not courteous, all tasks have
to play nice.

> > use cfs_rq->next to pass the scheduler a HINT of what you would LIKE to
> > happen.
> 
> Hint is fine, so long as the scheduler seriously considers it.

It will take the hint if the target the target hasn't had too much cpu. 

> > If the current task on that rq is also in your group, resched
> > it, then IFF the task you would like to run isn't too far right, it'll
> > be selected.  If the current task is not one of yours, tough, you can
> > set cfs_rq->next and hope it doesn't get overwritten, but you may not
> > preempt a stranger.  If you happen to be sharing an rq, cool, you
> > accomplished your yield_to().  If not, there's no practical way (I can
> > think of) to ensure that the target runs before you run again if you try
> > to yield, but you did your best to try to get him to the cpu sooner, and
> > in a manner that preserves fairness without dangerous vruntime diddling.
> >
> > Would that be good enough to stop (or seriously improve) cpu wastage?
> 
> The cross-cpu limitation is bothersome.  Since there are many cpus in 
> modern machines, particularly ones used for virt, the probability of the 
> two tasks being on the same cpu is quite low.

What would you suggest?  There is no global execution timeline, so if
you want to definitely run after this task, you're stuck with moving to
his timezone or moving him to yours.  Well, you could sleep a while, but
we know how productive sleeping is.

	-Mike



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/