mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Mitchell Erblich" <erblichs@earthlink.net>
To: "Rene Herman" <rene.herman@gmail.com>
Cc: <linux-kernel@vger.kernel.org>, "Ingo Molnar" <mingo@elte.hu>,
	"\"T. J. Brumfield\"" <enderandrew@gmail.com>
Subject: Re: about modularization
Date: Mon, 6 Aug 2007 14:48:01 -0700	[thread overview]
Message-ID: <000b01c7d873$76ce03c0$6501a8c0@earthlink.net> (raw)

Rene,

    Of the uni-processor systems currently that can run Linux, I would not
    doubt if  99.9999% percent are uni-cores. It will be probably
    3-5 years minimum before the multi-core processors will have any
    decent percentage of systems.

    And I am not suggesting not supporting them. I am only suggesting
   is wrt the schedular, bring the system up with a default schedular,
   and then load additional functionality based on the hardware/software
    requirements of the system.

    Thus, the fallout MIGHT be a uni-processor CFS that would not migrate
    tasks between multiple CPUs and as additional processors are brought
    online, migration could be enabled, and gang type scheduling,  whatever
    could be then used.


    IMO, if their is a fault (because of heat, etc) the user would rather
bring
    up the system in a degraded mode. Same reason applies to...
    boot -s..

    Mitchell Erblich
------------------------------


Rene Herman wrote:
>
> On 08/06/2007 10:20 PM, Mitchell Erblich wrote:
>
> >     Thus, a hybrid schedular approach could be taken
> >     that would default to a single uni-processor schedular
>
> What a brilliant idea in a world where buying a non multi core CPU is
> getting to be only somewhat easier than a non SMT one...
>
> Rene.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/


             reply	other threads:[~2007-08-06 21:48 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-08-06 21:48 Mitchell Erblich [this message]
2007-08-06 23:35 ` Rene Herman
2007-08-06 23:45   ` Rene Herman
  -- strict thread matches above, loose matches on Subject: below --
2007-08-06 20:20 Mitchell Erblich
2007-08-06 20:50 ` Rene Herman
2007-08-03 12:07 Scheduler Situation T. J. Brumfield
2007-08-03 13:00 ` debian developer
2007-08-03 15:28   ` about modularization Ingo Molnar
2007-08-03 13:19 ` Ingo Molnar
     [not found]   ` <cdc89fe60708030651s54b5f0e0j938450632cf621c5@mail.gmail.com>
2007-08-03 13:52     ` Fwd: " T. J. Brumfield
2007-08-03 15:02       ` Ingo Molnar
2007-08-03 15:13       ` Ingo Molnar
2007-08-03 17:47   ` Rene Herman
2007-08-03 18:59     ` Ingo Molnar
2007-09-01 22:02   ` Oleg Verych

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='000b01c7d873$76ce03c0$6501a8c0@earthlink.net' \
    --to=erblichs@earthlink.net \
    --cc=enderandrew@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=rene.herman@gmail.com \
    /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

all inboxes | Powered by JetHome®