Re: Zen kernel, what are advantages if any?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Kevin Kofler wrote:
> Roberto Ragusa wrote:
>> - a scheduler from Con Kolivas is developed for years and widely used,
>> merging it is always denied until someone else creates a "similar"
>> scheduler and it is accepted immediately
>>
>> [the scheduler is a core part of the kernel, so why a freshly written
>> one is preferred to a mature one?]
> 
> Because it was developed by Ingo Molnar, the maintainer of the scheduling 
> portion of the kernel. He knows what he's doing. He also provided a few 
> technical reasons of why his Completely Fair Scheduler is better than the 
> Con Kolivas staircase schedulers it was inspired by.

I know that it was Ingo Molnar who wrote the CFS.
Don't you think that being "the maintainer of the scheduling portion"
is an exact definition of "being in the right circles"? I'm not saying
that core developers have an easy way to merge low quality patches,
just that "we know you" is a factor when a decision has to be made.
I will not even say that this approach is wrong, I'm just saying that
this is how things actually are done.
Anyway, let me say that I remember performance regressions threads on
the LKML when CFS was merged: Ingo promptly worked on those.
And let me also cite that Ingo switched from "I don't like the approach"
to "thanks to Kolivas for inspiring the idea". To many this sounded
like a "I will keep fighting you for as long as enough to have my
implementation ready".

>> - the reiser4 filesystem has been released in 2004 (!) and has never
>> been accepted; ext4, instead, has been basically developed inside
>> the mainline kernel and a similar thing happens for btrfs
> 
> Because reiser4 is designed in a way which the Linux kernel developers said 
> is unacceptable and the reiser4 developers refused to change it. It does too 
> much in the file system instead of letting the other layers of the Linux 
> file system stack handle things (kinda like ZFS, for which the relevant 
> Linux kernel maintainers said they'd reject it even if it were acceptably 
> licensed due to this "everything in the file system" design).

IIRC an agreement was reached about avoiding the "plugin" stuff
and the "files are dirs" stuff.
There were other issues (in some cases purely stylistic, such as
debug macros) and I remember there was a lot of cleanup work done on
reiser4 to satisfy the requirements for a merging that never happened.
The end result has been that a potentially good filesystem has been
put aside for 6 years. And it is now obvious that it will never get
merged.

>> [a filesystem is something totally isolated, only people using it
>> can have problems; the rejection was justified by saying that Hans
>> Reiser is a difficult guy to cope with (which is probably true)]
> 
> FYI, Hans Reiser is now in prison for having killed his ex-wife and unlikely 
> to ever get out of it. (They're serious when they say "life in prison" over 
> in California.)

I know. This was included in my "which is probably true".
I didn't want to bring Hans' personal problems in this discussion,
especially as a form of respect for Nina's end.

>> Tuxonice is just another of the big "but why not?" denied projects.
> 
> There were concrete technical objections there too.

I remember the criticism about the progress bar in VGA mode
and the "why do you save the cache" (stupid) objection.
But, even in this case, nobody really sat down and tried to
discover what Tuxonice was doing better than the official
suspend; there had to be something, if it works where the other
doesn't, is faster at suspending/resuming, gives a fully
functional system immediately after resuming...

You can't deny that some projects are actively kept out of the
kernel even if they could be included in experimental form
for better refining and testing.
Multiple schedulers? No. An extra filesystem? No. An extra
suspend method? No.
On the other end... open doors to ext4, btrfs, kvm, nouveaue,
kms and I'm not sure how many memory allocators the kernel
is now including (sl*b).

My kernel contributions were never big, but I see there is
indeed a contrast between "please, merge as early as possible"
and "go away with this unfinished stuff".

-- 
   Roberto Ragusa    mail at robertoragusa.it
-- 
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
[Index of Archives]     [Older Fedora Users]     [Fedora Announce]     [Fedora Package Announce]     [EPEL Announce]     [Fedora Magazine]     [Fedora News]     [Fedora Summer Coding]     [Fedora Laptop]     [Fedora Cloud]     [Fedora Advisory Board]     [Fedora Education]     [Fedora Security]     [Fedora Scitech]     [Fedora Robotics]     [Fedora Maintainers]     [Fedora Infrastructure]     [Fedora Websites]     [Anaconda Devel]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [Fedora Fonts]     [ATA RAID]     [Fedora Marketing]     [Fedora Management Tools]     [Fedora Mentors]     [SSH]     [Fedora Package Review]     [Fedora R Devel]     [Fedora PHP Devel]     [Kickstart]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Fedora Legal]     [Fedora Kernel]     [Fedora OCaml]     [Coolkey]     [Virtualization Tools]     [ET Management Tools]     [Yum Users]     [Tux]     [Yosemite News]     [Gnome Users]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [Asterisk PBX]     [Fedora Sparc]     [Fedora Universal Network Connector]     [Libvirt Users]     [Fedora ARM]

  Powered by Linux