Messages in this thread | | | Date | Mon, 12 Jul 2010 08:55:04 -0500 (CDT) | From | Christoph Lameter <> | Subject | Re: [RFC PATCH] x86-64: software IRQ masking and handling |
| |
On Mon, 12 Jul 2010, Tejun Heo wrote:
> I'm not very convinced either. Nehalems are said to be able to do > cli-sti sequences every 13 cycles or so, which sounds pretty good and > managing it asynchronously might not buy anything. But what they said > was cli-sti bandwidth, probably meaning that if you do cli-sti's in > succession or tight loop, each iteration will take 13 cycles. So, > there still could be cost related to instruction scheduling.
Note that Andi has repeatedly pointed out that it is not the cli-sti instructions that cause the most latencies but the pushf/popf etc stack operations.
> It only took me a couple of days to get it working and the changes are > pretty localized, so I think it's worthwhile to see whether it > actually helps anything on x86. I'm thinking about doing raw IOs on > SSDs which isn't too unrealistic and heavy on both IRQ masking and IRQ > handling although actual hardware access cost might just drown any > difference and workloads which are heavy on memory allocations and > such might be better fit. If you have any better ideas on testing, > please let me know.
If it is a win for local_irq_save/restore then it will help any slab allocator because the alloc / free hotpath must disable interupts to be usable from hardware interrupps.
| |