Need ammo against BSD Fud

Need ammo against BSD Fud

[JF Martinez]

BSD people are writing tons of articles saying how superior BSD is
respective to Linux.  There is a danger they will impregnate people
with the idea: Linux=second rate system.  The Linux people tend to
know little about BSD so we are at pain to fire back.  And BSD people
tend to "forget" to mention those features Linux had years before BSD
like modules or ELF support.  I would really appreciate info about
features the Linux kernel has and BSDs haven't or about areas where
Linux outperforms BSDs.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Need ammo against BSD Fud

[Neil A. Carson]

JF Martinez wrote:

> BSD people are writing tons of articles saying how superior BSD is
> respective to Linux.  There is a danger they will impregnate people
> with the idea: Linux=second rate system.  The Linux people tend to
> know little about BSD so we are at pain to fire back.  And BSD people
> tend to "forget" to mention those features Linux had years before BSD
> like modules or ELF support.  I would really appreciate info about
> features the Linux kernel has and BSDs haven't or about areas where
> Linux outperforms BSDs.

Maybe it does, maybe it doesn't. The best thing to do is end most of
these silly advocacy wars, and neither 'side' retaliating is the best
way to do this. As a regular user of many of both systems, the constant
FUD from everyone and anyone is just pathetically annoying.

The more ammo that gets sent, the more the other side will just send
ammo back again. It's an endless cycle that will never end.

        Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Need ammo against BSD Fud

[Ralf Baechle]

On Fri, Sep 17, 1999 at 11:59:21PM +0200, JF Martinez wrote:

> BSD people are writing tons of articles saying how superior BSD is
> respective to Linux.  There is a danger they will impregnate people
> with the idea: Linux=second rate system.  The Linux people tend to
> know little about BSD so we are at pain to fire back.  And BSD people
> tend to "forget" to mention those features Linux had years before BSD
> like modules or ELF support.  I would really appreciate info about
> features the Linux kernel has and BSDs haven't or about areas where
> Linux outperforms BSDs.

Ignore them.  Saves alot of nerves.  The Linux market is so explosive
that BSD is already more or less meaningless and it will become even
more meaningless in the future.  This is not about technical arguments.

  Ralf
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Need ammo against BSD Fud

[JF Martinez]

> 
> JF Martinez wrote:
> 
> > BSD people are writing tons of articles saying how superior BSD is
> > respective to Linux.  There is a danger they will impregnate people
> > with the idea: Linux=second rate system.  The Linux people tend to
> > know little about BSD so we are at pain to fire back.  And BSD people
> > tend to "forget" to mention those features Linux had years before BSD
> > like modules or ELF support.  I would really appreciate info about
> > features the Linux kernel has and BSDs haven't or about areas where
> > Linux outperforms BSDs.
> 
> Maybe it does, maybe it doesn't. The best thing to do is end most of
> these silly advocacy wars, and neither 'side' retaliating is the best
> way to do this. As a regular user of many of both systems, the constant
> FUD from everyone and anyone is just pathetically annoying.
> 

One of my fears is that BSD one day becomes the "saviour" of
proprietary software due to the fact BSD licensed software can be
reused legally and without provokinhg a scandal who isbad for PR).  So
one day those attacks could be coordinated by companies wanting people
switching from Linux to BSD and then issue a proprietary BSD with
additional bells and whistles.  First step would be in making people
believe that BSD is superior to Linux

> The more ammo that gets sent, the more the other side will just send
> ammo back again. It's an endless cycle that will never end.
> 

No I don't want to start an "editors war" but I need info in order to
restablish truth: I fear co,nsequences of one sided propaganda.  I
catched the BSD people in a couple of occasions while lying by
omission.

I think BSD is probably suprior in some fields but I can't beleieve
there is nothing wheere Linux doesn't beat the pants of BSD.  There is
alw that nothing is superior in every field.

-- 
			Jean Francois Martinez

Project Independence: Linux for the Masses
http://www.independence.seul.org

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Need ammo against BSD Fud

[Rik van Riel]

On Fri, 17 Sep 1999, JF Martinez wrote:

> BSD people are writing tons of articles saying how superior BSD is
> respective to Linux.  There is a danger they will impregnate
> people with the idea: Linux=second rate system.

The BSD VM system _is_ better than the Linux one, but AFAIK
that's about the only part where we lag in such a way that
people can actually notice a difference.

I think it's time to stop the advocacy and start the design
of a better Linux VM system. The first part would be a real
zoned memory allocator. More in my next mail...

Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
work at:	http://www.reseau.nl/
home at:	http://www.nl.linux.org/~riel/

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: Need ammo against BSD Fud

[James Simmons]

On Sun, 19 Sep 1999, Rik van Riel wrote:

> On Fri, 17 Sep 1999, JF Martinez wrote:
> 
> > BSD people are writing tons of articles saying how superior BSD is
> > respective to Linux.  There is a danger they will impregnate
> > people with the idea: Linux=second rate system.
> 
> The BSD VM system _is_ better than the Linux one, but AFAIK
> that's about the only part where we lag in such a way that
> people can actually notice a difference.
> 
> I think it's time to stop the advocacy and start the design
> of a better Linux VM system. The first part would be a real
> zoned memory allocator. More in my next mail...

We need to worry about making a better kernel. I don't know
nothing about BSD VM svs linux  VM but I do know linux needs a more
uniform  resource manager to make module writing easier. Having things
like write_b  vary from platform to platform makes life a real nightmare
for module writers. Also thier is a real lack of docs on how to make
drivers portable to all platforms. Of course this will be tackled in
2.5.x. 




--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

SV: Need ammo against BSD Fud

[Hans Eric Sandström]

This was on Linux-mm Some time ago:


Date: Wed, 13 Jan 1999 23:20:22 -0800 (PST)
From: Matthew Dillon <dillon@apollo.backplane.com>
Message-Id: <199901140720.XAA22609@apollo.backplane.com>
To: "John S. Dyson" <root@dyson.iquest.net>, dg@root.com, jkh@FreeBSD.ORG
Cc: hackers@FreeBSD.ORG
Subject: Review and report of linux kernel VM
Sender: owner-freebsd-hackers@FreeBSD.ORG

General Overview

    I've been looking at the linux kernel VM - mainly just to see what they've
    changed since I last looked at it.  It's quite interesting... not bad at
    all though it is definitely a bit more memory-resource-intensive then
    FreeBSD's.  However, it needs a *lot* of work when it comes to freeing 
    up pages. 

    I apologize in advance for any mistakes I've made!

    Basically, the linux kernel uses persistent hardware-level page tables
    in a mostly platform-independant fashion.  The function of the persistent
    page tables is roughly equivalent to the function of FreeBSD's vm_object's.
    That is, the page tables are used to manage sharing and copy-on-write
    functions for VM objects.

    For example, when a process fork()'s, pages are duplicated literally by
    copying pte's.  Writeable MAP_PRIVATE pages are write-protected and marked
    for copy-on-write.  A global resident-page array is used to keep track
    of shared reference counts.  

    Swapped-out pages are also represented by pte's and also marked for 
    copy-on-write as appropriate.  The swap block is stored in the PFN 
    area of the pte (as far as I can tell).  The swap system keeps a separate
    shared reference count to manage swap usage.  The overhead is around 
    3 bytes per swap page (whether it is in use or not), and another pte-sized
    (int usually) field when storing the swap block in the pagetable.

    Linux cannot swap out its page tables, mainly due to the direct use of
    the page tables in handling VM object sharing.

    In general terms, linux's VM system is much cleaner then FreeBSD's... and
    I mean a *whole lot* cleaner, but at the cost of eating some extra memory.
    It isn't a whole lot of extra memory - maybe a meg or two for a typical
    system managing a lot of processes, and much less for typical 'small'
    systems.  They are able to completely avoid the vm_object stacking
    (and related complexity) that we do, and they are able to completely
    avoid most of the pmap complexity in FreeBSD as well.

    Linux appears to implement a unified buffer cache.  It's pretty 
    straight forward except the object relationship is stored in
    the memory-map management structures in each process rather then
    in a vm_object type of structure.

    Linux appears to map all of physical memory into KVM.  This avoids
    FreeBSD's (struct buf) complexity at the cost of not being able to 
    deal with huge-memory configurations.  I'm not 100% sure of this, but
    its my read of the code until someone corrects me.

Problems

    Swap allocation is terrible.  Linux uses a linear array which it scans
    looking for a free swap block.  It does a relatively simple swap
    cluster cache, but eats the full linear scan if that fails which can be
    terribly nasty.  The swap clustering algorithm is a piece of crap, 
    too -- once swap becomes fragmented, the linux swapper falls on its face.
    It does read-ahead based on the swapblk which wouldn't be bad if it
    clustered writes by object or didn't have a fragmentation problem.
    As it stands, their read clustering is useless.  Swap deallocation is 
    fast since they are using a simple reference count array. 

    File read-ahead is half-hazard at best.

    The paging queues ( determing the age of the page and whether to 
    free or clean it) need to be written... the algorithms being used
    are terrible.

     * For the nominal page scan, it is using a one-hand clock algorithm.  
       All I can say is:  Oh my god!  Are they nuts?  That was abandoned
       a decade ago.  The priority mechanism they've implemented is nearly
       useless.

     * To locate pages to swap out, it takes a pass through the task list. 
       Ostensibly it locates the task with the largest RSS to then try to
       swap pages out from rather then select pages that are not in use.
       From my read of the code, it also botches this badly.

    Linux does not appear to do any page coloring whatsoever, but it would
    not be hard to add it in.

    Linux cannot swap-out its page tables or page directories.  Thus, idle
    tasks can eat a significant amount of memory.  This isn't a big deal for
    most systems ( small systems: no problem.  Big systems: probably have lots
    of memory anyway ).  But, mmap()'d files can create a significant burden
    if you have a lot of forked processes ( news, sendmail, web server, 
    etc...).  Not only does Linux have to scan the page tables for all the
    processes mapping the file, whether or not they are actively using the
    page being checked for, but Linux's swapout algorithm scans page tables
    and, effectively, makes redundant scans of shared objects.

     What FreeBSD can learn

    Well, the main thing is that the Linux VM system is very, very clean
    compared to the FreeBSD implementation.  Cleaning up FreeBSD's VM system
    complexity is what I've been concentrating on and will continue to 
    concentrate on.   However, part of the reason that FreeBSD's VM system 
    is more complex is because it does not use the page tables to store 
    reference information.  Instead, it uses the vm_object and pmap modules.
    I actually like this feature of FreeBSD.  A lot. 

    The biggest thing we need to do to clean up our VM system is, basically,
    to completely rewrite the struct buf filesystem buffering mechanism to
    make it much, much less complex - basically it should only be used as
    placeholders for read and write ops and not used to cache block number
    mappings between the files and the VM system, nor should it be used to
    map pages into KVM.  Separating out these three mechanisms into three
    different subsystems would simplify the code enormously, I think.  For
    example, we could implement a simple vm_object KVM mapping mechanism
    using FreeBSD's existing vm_object stacking model to map portions of a
    vm_object (aka filesystem partition) into KVM.

    Linux demarks interrupts from supervisor code much better then we do.
    If we move some of the more sophisticated operational capabilities
    out of our interrupt subsystem, we could get rid of most of the spl*()
    junk we currently have to do.  This is a real sore spot in current
    FreeBSD code.  Interrupts are just too complex.  I'd also get rid of
    FreeBSD's intermediate 'software interrupt' layer, which is able to
    do even more complex things then hard interrupt code.  The latency
    considerations just don't make any sense verses running pending software
    interrupts synchronously in tsleep(), prior to actually sleeping.  We 
    need to do this anyway ( or move softints to kernel threads ) to be able
    to take advantage of SMP mechanisms.  The *only* thing our interrupts
    should be allowed to do is finish I/O on a page or use zalloc().  

-Matt

Matthew Dillon 
<dillon@backplane.com>



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: SV: Need ammo against BSD Fud

[Andrea Arcangeli]

[..]
>    shared reference count to manage swap usage.  The overhead is around 
>    3 bytes per swap page (whether it is in use or not), and another pte-sized

The swap_map only needs two bytes per swap page.

>    Linux appears to map all of physical memory into KVM.  This avoids
>    FreeBSD's (struct buf) complexity at the cost of not being able to 
>    deal with huge-memory configurations.  I'm not 100% sure of this, but

In linux 2.3.x it's just been merged the additional code to handle huge
memory configurations without adding any real complexity to the code.

>    Swap allocation is terrible.  Linux uses a linear array which it scans
>    looking for a free swap block.  It does a relatively simple swap
>    cluster cache, but eats the full linear scan if that fails which can be
>    terribly nasty.  The swap clustering algorithm is a piece of crap, 
>    too -- once swap becomes fragmented, the linux swapper falls on its face.
>    It does read-ahead based on the swapblk which wouldn't be bad if it
>    clustered writes by object or didn't have a fragmentation problem.
>    As it stands, their read clustering is useless.  Swap deallocation is 

I fixed this in 2.3.x. I implemented an anti-swap-fragmentation algorithm
and it's just merged in 2.3.18.

>    File read-ahead is half-hazard at best.

read-ahead simply read ahead in the swap. As the swap is going to be low
fragmented these days also the swap readahead will improve.

>    The paging queues ( determing the age of the page and whether to 
>    free or clean it) need to be written... the algorithms being used
>    are terrible.

I implemented a real page-LRU mixed with the reference bit that is set at
every search hit in the buffer cache and in the page cache. My code is
just in 2.3.x.

>     * For the nominal page scan, it is using a one-hand clock algorithm.  
>       All I can say is:  Oh my god!  Are they nuts?  That was abandoned
>       a decade ago.  The priority mechanism they've implemented is nearly
>       useless.

My page-LRU in 2.3.x kills completly the clock algorithm.

>     * To locate pages to swap out, it takes a pass through the task list. 
>       Ostensibly it locates the task with the largest RSS to then try to
>       swap pages out from rather then select pages that are not in use.

Wrong. This is wrong also for 2.2.x as we swapout pages that have not the
accessed bit set in the pte.

>    Linux does not appear to do any page coloring whatsoever, but it would
>    not be hard to add it in.

It seems that page colouring is not interesting for i386 (except for
some not usual case).

Andrea

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: SV: Need ammo against BSD Fud

[James Simmons]

> >    Linux does not appear to do any page coloring whatsoever, but it would
> >    not be hard to add it in.
> 
> It seems that page colouring is not interesting for i386 (except for
> some not usual case).

Whats page colouring?

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/

Re: SV: Need ammo against BSD Fud

[David Mentr'e]

James Simmons <jsimmons@edgeglobal.com> writes:

> Whats page colouring?

This is a scheme that tries to allocate pages to minimize cache
conflicts.

More precisely : if a process need a page, the kernel tries to give him
a page that will not conflict (that is to say will use a different cache
set) with its actual set of pages.

Some "academical" studies have shown that some gain are
possible. However I do not now any successful real-life implementation
of page colouring. 

Some time ago, David Miller (of sparc, ultrasparc and gcc-sparc64 fame)
implemented a minimal coulouring support. Should be in some archives.


david
-- 
 David.Mentre@irisa.fr -- http://www.irisa.fr/prive/dmentre/
 Opinions expressed here are only mine.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/