A Possible 2.5 Idea, maybe?

A Possible 2.5 Idea, maybe?

[Brent D. Norris]

Recently one more than one subject there have been comments along the
lines of, "Do x, y and z because it would be great on desktops" and then
someone else will say "NO! becausing doing x, y, and z will make servers
run slow."  Then as a final note someone else will say "Do y and z, but
not x, because that will make my handheld linux project a lot better."
Now whatever is eventually decided in each discusion, normally one
group/user walks away feeling they are getting the shortend of the stick.

Now many of these things are configurable.  If it is the amount of
messages that the boot of the kernel makes or even the "motivation" and
actions that the VM takes.  It seems possible to configure the kernel so
that it would work optimally for each of the groups.  The problem is that
the code in these sections is having to work in too different of
situations.  Example : The VM is now somewhat more tweaked for servers
than it was previously.  Many people were concerned about the
"interactivity" of it.  Now it seems that it would be possible to change
the vm code so that it worked better for desktop users, but the
maintainers are not eager to do that because it would slow linux down in
the server market.

This all stems from one problem, which is a really great problem to have
if you must have a problem.  Linux is spreading to largely different
kinds of machines with many different purposes.  Microsoft solved this
problem by having several different kernels (NT code base for servers, 9x
code base for desktops, CE code base for handhelds), and this is somewhat
like what the "forking is a good thing" messge recommended for linux.  I
disagree with that concept though.  It is easy to see the trouble
microsoft is having with that and now they are trying to slowly merge the
two (NT,9x) together.

Instead of forking the kernel or catering only to one group, instead why
not try this:  Using the new CML2 tools and rulesets, make it possible to
have the kernel configured for the type of job it will be doing?  Just
like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
and configures options for that, have it ask people "Is your machine a
server, workstation, embedded/handheld?" and configure things in the
kernel like the VM, bootup and others to optimize it for that job type?

Brent Norris

Executive Advisor -- WKU-Linux

Re: A Possible 2.5 Idea, maybe?

[Patrick Mauritz]

On Fri, Jun 29, 2001 at 08:17:25AM -0500, Brent D. Norris wrote:
> Instead of forking the kernel or catering only to one group, instead why
> not try this:  Using the new CML2 tools and rulesets, make it possible to
> have the kernel configured for the type of job it will be doing?  Just
> like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
> and configures options for that, have it ask people "Is your machine a
> server, workstation, embedded/handheld?" and configure things in the
> kernel like the VM, bootup and others to optimize it for that job type?
that could be the "easy == end-user" setup
why can't there be two (possibly similar but tweaked) VMs (and other stuff as well)
be in the source so everyone has to choose exactly one for his kernel?

patrick mauritz
-- 
,------------------------------------------------------------------------.
>            Fighting for peace is like fucking for virginity            <
|------------------------------------------------------------------------|
>        The Forthcoming OpenBIOS | www.freiburg.linux.de/openbios       <
`------------------------------------------------------------------------'
          because light travels faster than sound, some people
           appear to be intelligent, until you hear them speak.

Re: A Possible 2.5 Idea, maybe?

[Dan Podeanu]

On Fri, 29 Jun 2001, Brent D. Norris wrote:

> Recently one more than one subject there have been comments along the
> lines of, "Do x, y and z because it would be great on desktops" and then
> someone else will say "NO! becausing doing x, y, and z will make servers
> run slow."  Then as a final note someone else will say "Do y and z, but
> not x, because that will make my handheld linux project a lot better."
> Now whatever is eventually decided in each discusion, normally one
> group/user walks away feeling they are getting the shortend of the stick.

Ok, this is a problem. Though it was sort of discussed before when someone
came with the idea of creating a 'home' linux-kernel edition (yuck!).

> Now many of these things are configurable.  If it is the amount of
> messages that the boot of the kernel makes or even the "motivation" and
> actions that the VM takes.  It seems possible to configure the kernel so
> that it would work optimally for each of the groups.  The problem is that
> the code in these sections is having to work in too different of
> situations.  Example : The VM is now somewhat more tweaked for servers
> than it was previously.  Many people were concerned about the
> "interactivity" of it.  Now it seems that it would be possible to change
> the vm code so that it worked better for desktop users, but the
> maintainers are not eager to do that because it would slow linux down in
> the server market.

Thats why we have /proc/... To echo things into it.

> This all stems from one problem, which is a really great problem to have
> if you must have a problem.  Linux is spreading to largely different
> kinds of machines with many different purposes.  Microsoft solved this
> problem by having several different kernels (NT code base for servers, 9x
> code base for desktops, CE code base for handhelds), and this is somewhat
> like what the "forking is a good thing" messge recommended for linux.  I
> disagree with that concept though.  It is easy to see the trouble
> microsoft is having with that and now they are trying to slowly merge the
> two (NT,9x) together.

Several kernel threads are hard to maintain, hard to evolve, hard to
bugfix, modify patches, etc. Mainly, we should have a single kernel that
can be tuned to fit people's needs.


> Instead of forking the kernel or catering only to one group, instead why
> not try this:  Using the new CML2 tools and rulesets, make it possible to
> have the kernel configured for the type of job it will be doing?  Just
> like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
> and configures options for that, have it ask people "Is your machine a
> server, workstation, embedded/handheld?" and configure things in the
> kernel like the VM, bootup and others to optimize it for that job type?

IMO, the Linux distributions out there should configure the kernel based
on the type of system the (l[inux])user wants. Those who have the balls to
compile their own system should know such things anyway. The rest, better
rely on the distribution default and/or ask around and get some more
info [the kernel configuration help is explicit enough anyway, given a
decent level of common sense is used].


Dan.

Re: A Possible 2.5 Idea, maybe?

[Brent D. Norris]

> Thats why we have /proc/... To echo things into it.

I don't know of a proc entry that lets the user tell the VM not to cache
as much or use swap in a different manner.

> Several kernel threads are hard to maintain, hard to evolve, hard to
> bugfix, modify patches, etc. Mainly, we should have a single kernel that
> can be tuned to fit people's needs.

I agree that keeping several threads would be difficult, but is there not
a way to have certain values plugged into the code for something like
cache pressure before swapping, or extended boot messages instead of a
quiet boot?  These values would be dependant on the config options that
were selected in the config.  I am not talking about forking the kernel.
I am instead talking about a process to select a different concept that
the same kernel runs under and have this concept selected at compile time.

> IMO, the Linux distributions out there should configure the kernel based
> on the type of system the (l[inux])user wants. Those who have the balls to
> compile their own system should know such things anyway. The rest, better
> rely on the distribution default and/or ask around and get some more
> info [the kernel configuration help is explicit enough anyway, given a
> decent level of common sense is used].

This leaves several people out in the rain though.  First how would a
distro make a system that works well for the desktop users if the kernel
is designed to work well on servers?  Also I should be able to run debian
on my desktop if I want without having to suffer through interactivity
issues, because debian builds their distros for servers and has most of
the hard drives cached.  Also I know several people that recompile kernels
and such, but have no clue as the process to go through to optimize it for
their particular setup.  If people are hoping that linux will move into
other markets besides servers then you cannot have the attitude that
everyone has to suffer with a) what the distros give them or b) be come
fluent enought in kernel programming and desgin to be able to edit the
code so that it works better for them.

Brent Norris

Executive Advisor -- WKU-Linux

Re: A Possible 2.5 Idea, maybe?

[Philips]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

Patrick Mauritz wrote:
> 
> On Fri, Jun 29, 2001 at 08:17:25AM -0500, Brent D. Norris wrote:
> > Instead of forking the kernel or catering only to one group, instead why
> > not try this:  Using the new CML2 tools and rulesets, make it possible to
> > have the kernel configured for the type of job it will be doing?  Just
> > like CML2 asks our CPU type (i386, alpha, althon ...) and then goes out
> > and configures options for that, have it ask people "Is your machine a
> > server, workstation, embedded/handheld?" and configure things in the
> > kernel like the VM, bootup and others to optimize it for that job type?
> that could be the "easy == end-user" setup
> why can't there be two (possibly similar but tweaked) VMs (and other stuff as well)
> be in the source so everyone has to choose exactly one for his kernel?
> 

	there are patches for plug-able TCP/IP stacks.
	filesystems are already plug-able (someone need journaling, some one needs
quoatas, some needs nothing).
	there are patches for plug-able task scheduler.

	If I could choose what filesystem to run on / - it impact performance greatly
- why can't I choose how my tasks are scheduled? how my packets are going to
NIC?

	IMHO great idea. I think this will improve portability. And embeded guys will
be in permanent satisfaction ;-)


	But I'm afraid this won't happen in 2.5 - this kind of change require well
defined and stable internal interfaces. So this is really huge amount of work.
	This would be one little step toward the microkernel architecture (like Hurd).
Good again :-)

[-- Attachment #2: Card for Philips --]
[-- Type: text/x-vcard, Size: 407 bytes --]

begin:vcard 
n:Filiapau;Ihar
tel;pager:+375 (0) 17 2850000#6683
tel;fax:+375 (0) 17 2841537
tel;home:+375 (0) 17 2118441
tel;work:+375 (0) 17 2841371
x-mozilla-html:TRUE
url:www.iph.to
org:Enformatica Ltd.;Linux Developement Department
adr:;;Kalinine str. 19-18;Minsk;BY;220012;Belarus
version:2.1
email;internet:philips@iph.to
title:Software Developer
note:(none)
x-mozilla-cpt:;18368
fn:Philips
end:vcard

Re: A Possible 2.5 Idea, maybe?

[Alexander Viro]

On Sat, 30 Jun 2001, Philips wrote:

> 	If I could choose what filesystem to run on / - it impact performance greatly

No, it doesn't. Most of lookups go outside of root and within root you
mostly deal with cached lookups from dcache (which doesn't give a damn for
fs type) and with page cache lookups for data (mostly in libc) (ditto).

[snip]

> 	This would be one little step toward the microkernel architecture (like Hurd).
> Good again :-)

	Hurd and architecture in one sentence? Uh-oh...