mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@digeo.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: "Martin J. Bligh" <mbligh@aracnet.com>,
	Christoph Hellwig <hch@sgi.com>, Robert Love <rml@tech9.net>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] set_cpus_allowed() for 2.4
Date: Sun, 08 Dec 2002 11:56:42 -0800	[thread overview]
Message-ID: <3DF3A3FA.D1571CCD@digeo.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0212081406270.2547-100000@localhost.localdomain>

Ingo Molnar wrote:
> 
> On Mon, 2 Dec 2002, Andrew Morton wrote:
> 
> > I have observed two problems with the new scheduler, both serious IMO:
> >
> > 1) Changed sched_yield() semantics.  [...]
> 
> we noticed this OpenOffice/StarOffice problem in July, while beta-testing
> RH 8.0. In July Andrea already had another yield implementation in his
> tree, which was addressing an unrelated yield()-related regression. I'd
> like to note here that StarOffice/OpenOffice sucked just as much under
> Andrea's yield() variant as the original (and 2.5) O(1) scheduler variant
> did.
> 
> So i talked to Andrea, and we agreed in a rough solution that worked
> sufficiently well for OpenOffice and the other regression as well. I
> implemented it and tested it for OpenOffice. You can see (an i suspect
> later incarnation) of that implementation in Andrea's current tree. My
> position back then was that we should not try to move the arguably broken
> 2.4 yield() implementation to 2.5.
> 
> So this is the history of O(1) yield().
> 
> fortunately, things have changed since July, since due to NPTL threading
> the architectural need for user-space yield() has decreased significantly
> (NPTL uses futexes, no yielding anywhere), so the only worry is behavioral
> compatibility with LinuxThreads (and other yield() users). I'll forward
> port the new (well, old) yield() semantics to 2.5 as well, which will be
> quite similar to the yield() implementation in Andrea's tree.
> 
> there's another (this time unique) bit implemented by Andrea, a variant of
> giving newly forked children priority in a more subtle way - i'm testing
> this change currently, to see whether it has any positive effect on
> compilation workloads.
> 
> does this clarify things?
> 

Yes, thanks.  Will we also be seeing the "interactivity estimator" fixes
in 2.5?

  reply	other threads:[~2002-12-08 19:49 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-03  0:26 Christoph Hellwig
2002-12-02 17:24 ` Jeff Garzik
2002-12-02 18:57   ` Robert Love
2002-12-03  0:51   ` Christoph Hellwig
2002-12-02 17:50 ` Martin J. Bligh
2002-12-02 18:50   ` Adrian Bunk
2002-12-02 19:12     ` Robert Love
2002-12-02 19:30   ` Andrew Morton
2002-12-02 19:50     ` Andrea Arcangeli
2002-12-03 20:49       ` Andrew Morton
2002-12-03 21:09         ` Martin J. Bligh
2002-12-04  0:09           ` Andrea Arcangeli
2002-12-04  0:06         ` Andrea Arcangeli
2002-12-04  0:30           ` Andrew Morton
2002-12-04  0:42             ` Andrea Arcangeli
2002-12-04  1:03               ` William Lee Irwin III
2002-12-04  9:25                 ` William Lee Irwin III
2002-12-04  1:14               ` Andrew Morton
2002-12-04  1:21                 ` Andrea Arcangeli
2002-12-04  2:14                   ` Andrew Morton
2002-12-06 18:11                 ` William Lee Irwin III
2002-12-08 13:23     ` Ingo Molnar
2002-12-08 19:56       ` Andrew Morton [this message]
2002-12-09 20:13         ` Ingo Molnar
2002-12-03  1:11   ` Christoph Hellwig
2002-12-02 18:59     ` Robert Love
2002-12-02 22:47     ` Alan Cox
2002-12-02 22:38       ` Christoph Hellwig
2002-12-02 22:41         ` Robert Love
2002-12-07 16:55           ` bill davidsen
  -- strict thread matches above, loose matches on Subject: below --
2002-12-13 23:08 Christoph Hellwig
2002-12-13 21:34 ` Adrian Bunk
2002-12-14  4:55   ` Christoph Hellwig
2002-12-09 20:19 kernel
2002-12-09  3:02 Jim Houston
2002-10-01 23:03 Robert Love
2002-10-02 13:01 ` Christoph Hellwig
2002-10-02 15:00   ` Robert Love
2002-11-05  3:37 ` Christoph Hellwig
2002-11-06 15:32   ` Adrian Bunk
2002-11-07 21:42     ` Christoph Hellwig
2002-12-02 17:12   ` Mikael Pettersson
2002-12-03  0:51     ` Christoph Hellwig
2002-12-02 17:47       ` Mikael Pettersson
2002-12-02 19:10         ` Robert Love

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3DF3A3FA.D1571CCD@digeo.com \
    --to=akpm@digeo.com \
    --cc=hch@sgi.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mbligh@aracnet.com \
    --cc=mingo@elte.hu \
    --cc=rml@tech9.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome