> * These lists are terminated by ELIST_END constant instead of NULL.
list.h lists are not terminated by NULL.
> * It speeds up list manipulations because next->pprev is always accessible.
such are list.h lists ...
> * They are anchored by single pointer - it saves 50% of memory
> * occupied by hashtables.
i think this might be an interesting optimization, we always want to save
cache footprint - but this is not an unconditional move. This presumes
that the list-user never tries to really look up anchor->prev. There are
several usage types which want to append to the end of the queue. Eg.
waitqueues want to access anchor->prev. In 2.0 we had 'on the fly'
performance decisions which have put inodes at the end or at the beginning
of the hash chains - using elist.h lists removes the possibility of later
changing add-characteristics.
Also, the effect on SMP systems is interesting as well - we might end up
writing to __elist_end.pprev from many CPUs - causing that cacheline to
bounce around. This can be solved if __elist_end is properly aligned and
indexed by smp_processor_id() but then we introduce additional complexity
to elist_find(), on_elist() and init_*elist().
> + fast list scanning using elist_find() function.
> It is about 75% faster than original for long lists (5-element).
> (dcache, icache and buffer cache use it now)
and how did you time this 75% speedup? list.h is very simple already and
the finding functions did about what elist_find does.
-- mingo
-
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/