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
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
spend
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
> > 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
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 moment
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
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
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
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,
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
> 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
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
> 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
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 re-exec of a trivial shell script
forkload: constant
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 re-exec of a trivial shell script
forkload: constant
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
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 good
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
it's
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 developers for
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 that
it's
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 we can't
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 bad/ok
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 think
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 bugfix for
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 could
28 matches
Mail list logo
