David Schwartz wrote:
There's a substantial performance hit for not yield, so we probably
want to investigate alternate semantics for it. It seems reasonable
for apps to say "let me not hog the CPU" without completely expiring
them. Imagine you're in the front of the line (aka queue) and you
spen
On 3/12/07, David Schwartz <[EMAIL PROTECTED]> wrote:
In no case is much of anything guaranteed, of course. (What can you do if
there's no other process to yield to?)
Perhaps if sched_yield()'s effects were cumulative inside a timeslice,
then eventually the calling task would get pushed far eno
> > There's a substantial performance hit for not yield, so we probably
> > want to investigate alternate semantics for it. It seems reasonable
> > for apps to say "let me not hog the CPU" without completely expiring
> > them. Imagine you're in the front of the line (aka queue) and you
> > spend a
On Sat, Mar 10, 2007 at 07:35:06PM -0600, Matt Mackall wrote:
> I've tested -mm2 against -mm2+noyield and -mm2+rsdl+noyield. The
> noyield patch simply makes the sched_yield syscall return immediately.
> Xorg and all tests are run at nice 0.
[skipped long and precise test report]
> Also note I co
On Sunday 11 March 2007 15:03, Matt Mackall wrote:
> On Sat, Mar 10, 2007 at 10:01:32PM -0600, Matt Mackall wrote:
> > On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote:
> > > Ok I don't think there's any actual accounting problem here per se
> > > (although I did just recently post a bug
On Sat, Mar 10, 2007 at 10:01:32PM -0600, Matt Mackall wrote:
> On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote:
> > Ok I don't think there's any actual accounting problem here per se
> > (although I did just recently post a bugfix for rsdl however I think
> > that's unrelated). What I
On Sun, Mar 11, 2007 at 01:28:22PM +1100, Con Kolivas wrote:
> >make -j 5 ccache
> > berylok good awful
> > galeon goodgood bad
> > mp3 goodgood bad
> > terminal goodgood bad/ok
> > mousegoodgood
On Sunday 11 March 2007 14:39, Andrew Morton wrote:
> > On Sun, 11 Mar 2007 14:59:28 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote:
> > > Bottom line: we've had a _lot_ of problems with the new yield()
> > > semantics. We effectively broke back-compatibility by changing its
> > > behaviour a lot, and
On Sun, 11 Mar 2007 13:28:22 +1100 "Con Kolivas" <[EMAIL PROTECTED]> wrote:
>> Well... are you advocating we change sched_yield semantics to a
>> gentler form?
On Sat, Mar 10, 2007 at 07:16:14PM -0800, Andrew Morton wrote:
> From a practical POV: our present yield() behaviour is so truly awful tha
> On Sun, 11 Mar 2007 14:59:28 +1100 Con Kolivas <[EMAIL PROTECTED]> wrote:
> > Bottom line: we've had a _lot_ of problems with the new yield() semantics.
> > We effectively broke back-compatibility by changing its behaviour a lot,
> > and we can't really turn around and blame application developer
On Sunday 11 March 2007 14:16, Andrew Morton wrote:
> > On Sun, 11 Mar 2007 13:28:22 +1100 "Con Kolivas" <[EMAIL PROTECTED]>
> > wrote: Well... are you advocating we change sched_yield semantics to a
> > gentler form?
> >
> >From a practical POV: our present yield() behaviour is so truly awful that
> On Sun, 11 Mar 2007 13:28:22 +1100 "Con Kolivas" <[EMAIL PROTECTED]> wrote:
> Well... are you advocating we change sched_yield semantics to a
> gentler form?
>From a practical POV: our present yield() behaviour is so truly awful that
it's basically always a bug to use it. This probably isn't a
On 11/03/07, Matt Mackall <[EMAIL PROTECTED]> wrote:
I've tested -mm2 against -mm2+noyield and -mm2+rsdl+noyield. The
noyield patch simply makes the sched_yield syscall return immediately.
Xorg and all tests are run at nice 0.
Loads:
memload: constant memcpy of 16MB buffer
execload: constant r
13 matches
Mail list logo
