[9fans] some light reading

[9fans] some light reading

[andrey mirtchovski]

"Developing Simple and Efficient Package System using Union Mounts":

		http://www.osnews.com/story.php?news_id=8069

check the comments too -- seems like 2000 binds would be 'very inefficient'...

i just had to check for myself:

	plan9% ramfs
	plan9% cd /tmp
	plan9% time ls
	0.00u 0.00s 0.00r 	 ls
	plan9% cp /bin/bind bind.tmp
	plan9% cat > bind.rc
	#!/bin/rc

	for (i in `{seq 1 2000}) bind.tmp -a /usr/andrey/tmp .
	plan9% chmod 775 bind.rc
	plan9% time bind.rc
	0.27u 1.58s 2.52r 	 bind.rc
	plan9% time ls > /dev/null
	13.17u 0.40s 15.25r 	 ls
	plan9% ls | wc -l
	  46002
	plan9% ls /usr/andrey/tmp | wc -l
	     23
	plan9% echo '46000/23' | hoc
	2000
	plan9%

andrey

Re: [9fans] some light reading

[Tim Newsham]

> "Developing Simple and Efficient Package System using Union Mounts":
[...]
> check the comments too -- seems like 2000 binds would be 'very
> inefficient'...

This has been discussed a number of times in VSTa circles
(and I'm sure elsewhere).

Yes, it is inefficient, but no more so than if you have a shell
which searches $PATH each time it runs a command.  If the shell
caches the lookups you can tradeoff some space for some time, of
course.  I'm not familiar with the mount point searching code
in plan9, but I bet part of the inefficiency you are seeing is just
because the code wasn't written with large mount tables in mind.

All that is going on here is that the search mechanism is being
removed from several ad-hoc places (shell $PATH, dynamic loader
LD_LIBRARY_PATH, man $MANPATH, etc) and being pushed down into
a general mechanism in the kernel (or elsewhere in some operating
systems).  I think its a good idea.

Of course I doubt the BSD or linux crowd would follow this up
by removing the various ad-hoc search mechanisms (partially because
namespaces arent customizable on a per-user basis, and partially
because they tend to add features, not remove them).

> andrey

Tim N.

Re: [9fans] some light reading

[boyd, rounin]

> Yes, it is inefficient, but no more so than if you have a shell
> which searches $PATH each time it runs a command.

nonsense.  $PATH involves an O(n) number of exec(2)'s
and syscalls are expensive and n is usually not small.  on
plan 9 n is 2 -- . and /bin and these two execs do all
the hard work in the kernel.

put the cache in the kernel, if such a thing is needed,
rather than replicating it badly n times in some horror
like bash.

Re: [9fans] some light reading

[andrey mirtchovski]

> Yes, it is inefficient, but no more so than if you have a shell
> which searches $PATH each time it runs a command.


tim, i was being sarcastic :) 15 seconds for 40000 files and 2 seconds
for 2000 binds is way better than what the guys in the comments
expected (remember, they haven't seen a working prototype of union
directories, at least not at userlevel, yet).

however, i'd be very interested to see the way the linux guys optimize
their kernel, shall they ever come to fully implement union
directories as in Plan 9 (linux is about doing things better, isn't
it?  remember the recent TLB flush flamewar :)

andrey

Re: [9fans] some light reading

[Boris Maryshev]

В сообщении от Четверг 19 Август 2004 03:00 andrey mirtchovski написал(a):
> > Yes, it is inefficient, but no more so than if you have a shell
> > which searches $PATH each time it runs a command.
>
> tim, i was being sarcastic :) 15 seconds for 40000 files and 2 seconds
> for 2000 binds is way better than what the guys in the comments
> expected (remember, they haven't seen a working prototype of union
> directories, at least not at userlevel, yet).
>
> however, i'd be very interested to see the way the linux guys optimize
> their kernel, shall they ever come to fully implement union
> directories as in Plan 9 (linux is about doing things better, isn't
> it?  remember the recent TLB flush flamewar :)
>
> andrey
Check out http://www.gobolinux.org/ You can try it on existing Linux machine 
using their shell script or you can install it or run from cd. They also have 
some kernel module. Creator claims he's not clueless.

boris
-- 
The universe is all a spin-off of the Big Bang.

Re: [9fans] some light reading

[Roman Shaposhnick]

On Thu, Aug 19, 2004 at 09:24:23AM +0300, Boris Maryshev wrote:
> В сообщении от Четверг 19 Август 2004 03:00 andrey mirtchovski написал(a):
> > > Yes, it is inefficient, but no more so than if you have a shell
> > > which searches $PATH each time it runs a command.
> >
> > tim, i was being sarcastic :) 15 seconds for 40000 files and 2 seconds
> > for 2000 binds is way better than what the guys in the comments
> > expected (remember, they haven't seen a working prototype of union
> > directories, at least not at userlevel, yet).
> >
> > however, i'd be very interested to see the way the linux guys optimize
> > their kernel, shall they ever come to fully implement union
> > directories as in Plan 9 (linux is about doing things better, isn't
> > it?  remember the recent TLB flush flamewar :)
> >
> > andrey
> Check out http://www.gobolinux.org/ You can try it on existing Linux machine 
> using their shell script or you can install it or run from cd. They also have 
> some kernel module. 

  That's what petrifies me. I always wondered if there should be a sentence
  for kernel abuse. Have you seen their ioctls ? 

Thanks,
Roman.

Re: [9fans] some light reading

[Charles Forsyth]

>>I always wondered if there should be a sentence for kernel abuse.

you must spend your time reading the source code.
with plan 9, it's rehabilitation.  with xBSD, it's purgatory.
with linux, it's hard labour.

Re: [9fans] some light reading

[boyd, rounin]

> with linux, it's hard labour.

pass me the sledgehammer ...