b_freelist TAILQ/SLIST

[Alexander Motin]

On 28.06.2013 18:14, Adrian Chadd wrote:
> .. i'd rather you narrow down _why_ it's performing better before committing it.

If you have good guesses -- they are welcome. All those functions are so 
small, that it is hard to imagine how congestion may happen there at 
all. I have strong feeling that lock spinning there consumes 
incomparably much more CPU time then the locked region itself could consume.

> Otherwise it may just creep up again after someone does another change
> in an unrelated part of the kernel.

Big win or small, TAILQ is still heavier then STAILQ, while it is not 
needed there at all.

> You're using instructions-retired; how about using l1/l2 cache loads,
> stores, etc? There's a lot more CPU counters available.

I am using unhalted-cycles, that is more reasonable then 
instructions-retired. What's about other counters, there are indeed a 
lot of them, but it is not always easy to get something useful out of them.

> You have a very cool problem to solve. If I could reproduce it locally
> I'd give you a hand.

You'd need a lot of hardware and patches to reproduce it in full. But if 
you like to see this with your own eyes, I can give you an SSH access to 
my test machine.

-- 
Alexander Motin