On Mon, 31 Jul 2000, Andi Kleen wrote:
> On Mon, Jul 31, 2000 at 08:03:26AM +0200, Linus Torvalds wrote:
> >
> >
> > On Mon, 31 Jul 2000, Andi Kleen wrote:
> > >
> > > Ok, it is worth about 13% for iget() on a K6-400 during cache trashing
> > > with empty file system read_inode.
> >
> > I'm not interested in made-up benchmarks that cannot be reproduced under
> > real load.
>
> I don't think it is more made up than e.g. lmbench doing getpid() all
> the time to test syscall latency.
So make up a benchmark that can be tested with a _system_call_.
Not something that requires a filesystem that cannot exist in real life.
> The other system is simulated by the
> cache trashing. Doing it completely from user space would probably
> add so many other variables and variances that the results would be hard
> to interpret.
Yes.
The other way to say the same thing is
"Doing it from user space might show that it's not a performance
optimization that cna be noticed".
See?
> It stands for hash yes. single_pointer_head_list would be more accurate, but
> I didn't like the sphlist name. Its most common use is probably hash tables,
> so I chose the h- prefix instead.
If it makes you feel any better, I would have hated "sphlist" even more.
Basically, I think it's the wrong level of abstraction. If it is
abstracted like a list, then I like the current lists more that do not
need conditionals in many of the common operations. If it were to be
abstraced as a hash thing, then I might like it.
Something like "hash_insert()" and "hash_remove()" etc would be
acceptable, but then you'd need to really make the abstraction layer
higher (ie implement some form of generic "hash_find()" etc). This might
well be worthwhile - I suspect there is quite a lot of common code in
inode/page/dentry hashing, and at that point the interface would be _more_
than "just another list implementation".
I do not like two pieces of code that basically do the equivalent thing,
is what I guess I'm saying. I prefer simplicity over something that cannot
even be measured on the performance side..
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:34 EST