Re: [9fans] kernel development: how not to

Re: [9fans] kernel development: how not to

[erik quanstrom]

sort of.  it's an extension.  here's the kerneltrap summary:

	http://kerneltrap.org/node/6506

what linux actually said is that COW games (e.g. for freebsd's zero-copy
socket code) are worse than just copying the data.

the real difference between bsd's stuff and what linus did is
the linux trick is an explict system call, not a vm game.
but he misses that adding strange system calls that parallel
read and write is even bigger trouble.  either your fundamental
object is a file (unix) or a block of memory (multix).  pick a
lane!  certainly don't mix the two at the same level.

linus may be right that the freebsd vm's techniques are broken.
i don't know.

the zero-copy idea is tantalizing.  it would be neat to allow the
network stacks or devdraw to live in a user-level fileserver
without a performance (2 copy) penalty.  but it may be the case
that allowing this trickery is more code than it is worth.

- erik

On Fri May  5 10:20:1CDT 2006, leimy2k@gmail.com wrote:
> Is the the vmslice that Linus told BSD people they were a bunch of
> retards for not having?
> 
> 
> 
> On 5/5/06, erik quanstrom <quanstro@quanstro.net> wrote:
> > the linux guys decided to implement system calls
> > "splice" and "tee".  splice concatinates the pages from
> > two files -- the vm equivalent of "cat a b".  tee
> > is the vm equivalent of its namesake.
> >
> >         http://lwn.net/Articles/181169/#Comments
> >
> > the best part is the conclusion -- "needs a bit more work".
> > ha!
> >
> > - erik

Re: [9fans] kernel development: how not to

[Dave Lukes]

Yawn.

After the Beserkeley folks implemented vread() and vwrite() in 4.1BSD
many people (including myself) saw the concept and thought
"why didn't they just detect that as a special case in read() and write()?":
exactly the same benefits without the new syscalls.

In the same way, most of the speed improvements for muck like splice(),
could probably be gained by tuning the current system
(and, hey, you might even speed up a couple of other things along the way).

Of course improving current functionality without complicating any 
visible interfaces
is far less fun that implementing the
    wankmyego(fuckme, im, so, clever, look, at, all, these, parameters, 
i, must, be, a, genius)
syscall.

Sigh,
    DaveL

erik quanstrom wrote:
> sort of.  it's an extension.  here's the kerneltrap summary:
>
> 	http://kerneltrap.org/node/6506
>
> what linux actually said is that COW games (e.g. for freebsd's zero-copy
> socket code) are worse than just copying the data.
>
> the real difference between bsd's stuff and what linus did is
> the linux trick is an explict system call, not a vm game.
> but he misses that adding strange system calls that parallel
> read and write is even bigger trouble.  either your fundamental
> object is a file (unix) or a block of memory (multix).  pick a
> lane!  certainly don't mix the two at the same level.
>
> linus may be right that the freebsd vm's techniques are broken.
> i don't know.
>
> the zero-copy idea is tantalizing.  it would be neat to allow the
> network stacks or devdraw to live in a user-level fileserver
> without a performance (2 copy) penalty.  but it may be the case
> that allowing this trickery is more code than it is worth.
>
> - erik
>
> On Fri May  5 10:20:1CDT 2006, leimy2k@gmail.com wrote:
>   
>> Is the the vmslice that Linus told BSD people they were a bunch of
>> retards for not having?
>>
>>
>>
>> On 5/5/06, erik quanstrom <quanstro@quanstro.net> wrote:
>>     
>>> the linux guys decided to implement system calls
>>> "splice" and "tee".  splice concatinates the pages from
>>> two files -- the vm equivalent of "cat a b".  tee
>>> is the vm equivalent of its namesake.
>>>
>>>         http://lwn.net/Articles/181169/#Comments
>>>
>>> the best part is the conclusion -- "needs a bit more work".
>>> ha!
>>>
>>> - erik
>>>       

Re: [9fans] kernel development: how not to

[erik quanstrom]

i agree with your point, but i think the problem with splice and tee is 
worse than that.

before complicating the system with this optimization, shouldn't a
real system doing real work (i.e. not benchmarking) be found where
splice and tee could help?

parameters change, the balance between cpu, memory b/w and i/o
changes over time and from machine to machine.

i wonder if splice is really faster than coping the buffer on a 
NUMA machine?

remember: in linux, as in life, it's ready, shoot, aim.

- erik

On Mon May  8 10:44:21 CDT 2006, davel@anvil.com wrote:
> Yawn.
> 
> After the Beserkeley folks implemented vread() and vwrite() in 4.1BSD
> many people (including myself) saw the concept and thought
> "why didn't they just detect that as a special case in read() and write()?":
> exactly the same benefits without the new syscalls.
> 
> In the same way, most of the speed improvements for muck like splice(),
> could probably be gained by tuning the current system
> (and, hey, you might even speed up a couple of other things along the way).
> 
> Of course improving current functionality without complicating any 
> visible interfaces
> is far less fun that implementing the
>     wankmyego(fuckme, im, so, clever, look, at, all, these, parameters, 
> i, must, be, a, genius)
> syscall.
> 
> Sigh,
>     DaveL
> 
> erik quanstrom wrote:
> > sort of.  it's an extension.  here's the kerneltrap summary:
> >
> > 	http://kerneltrap.org/node/6506
> >
> > what linux actually said is that COW games (e.g. for freebsd's zero-copy
> > socket code) are worse than just copying the data.
> >
> > the real difference between bsd's stuff and what linus did is
> > the linux trick is an explict system call, not a vm game.
> > but he misses that adding strange system calls that parallel
> > read and write is even bigger trouble.  either your fundamental
> > object is a file (unix) or a block of memory (multix).  pick a
> > lane!  certainly don't mix the two at the same level.
> >
> > linus may be right that the freebsd vm's techniques are broken.
> > i don't know.
> >
> > the zero-copy idea is tantalizing.  it would be neat to allow the
> > network stacks or devdraw to live in a user-level fileserver
> > without a performance (2 copy) penalty.  but it may be the case
> > that allowing this trickery is more code than it is worth.
> >
> > - erik
> >

Re: [9fans] kernel development: how not to

[David Leimbach]

Is the the vmslice that Linus told BSD people they were a bunch of
retards for not having?



On 5/5/06, erik quanstrom <quanstro@quanstro.net> wrote:
> the linux guys decided to implement system calls
> "splice" and "tee".  splice concatinates the pages from
> two files -- the vm equivalent of "cat a b".  tee
> is the vm equivalent of its namesake.
>
>         http://lwn.net/Articles/181169/#Comments
>
> the best part is the conclusion -- "needs a bit more work".
> ha!
>
> - erik
>

[9fans] kernel development: how not to

[erik quanstrom]

the linux guys decided to implement system calls
"splice" and "tee".  splice concatinates the pages from
two files -- the vm equivalent of "cat a b".  tee
is the vm equivalent of its namesake. 

	http://lwn.net/Articles/181169/#Comments

the best part is the conclusion -- "needs a bit more work".
ha!   

- erik