On Thu, 1 Nov 2007, Gregory Haskins wrote:Can you test under interesting loads? We're interested in: - is the unfairness fix really noticeable (or does it just move the problem somewhere else, and there is no real change in behaviour) - what is the performance impact? In particular, unfair spinlocks have the potential to perform much better. Not so much because the spinlock itself acts all that differently, but because being unfair also fundmanetally tends to keep the data structures that are *protected* by the spinlock on just one CPU. So "unfair" is obviously always bad. Except when it isn't. I'd personally like to merge the ticket spinlocks, but I'd really like to have people who have real loads where they matter actually also do some performance testing. Because I do think it will potentially be a performance downer. (I obviously hope it won't be, but..) Linus -
| david | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | -mm merge plans for 2.6.23 |
| Greg Kroah-Hartman | [PATCH 025/196] paride: Convert from class_device to device for block/paride |
| Henrique de Moraes Holschuh | [RFC] rfkill class rework |
git: | |
| Gerrit Renker | [PATCH 05/37] dccp: Cleanup routines for feature negotiation |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Johann Baudy | Packet mmap: TX RING and zero copy |
| David Miller | [GIT]: Networking |
