Re: [Patch 1/4] ipc/mqueue: improve performance of send/recv

[Nick Piggin]

On 2 May 2012 03:50, Doug Ledford <dledford@xxxxxxxxxx> wrote:

> Avg time to send/recv (in nanoseconds per message)
> Âwhen queue empty      Â305/288          Â349/318
> Âwhen queue full (65528 messages)
>  Âconstant priority   Â526589/823          Â362/314
>  Âincreasing priority  Â403105/916          Â495/445
>  Âdecreasing priority   73420/594          Â482/409
>  Ârandom priority    Â280147/920          Â546/436
>
> Time to fill/drain queue (65528 messages, in seconds)
> Âconstant priority     17.37/.12          Â.13/.12
> Âincreasing priority    Â4.14/.14          Â.21/.18
> Âdecreasing priority    12.93/.13          Â.21/.18
> Ârandom priority      Â8.88/.16          Â.22/.17
>
> So, I think the results speak for themselves. ÂIt's possible this
> implementation could be improved by cacheing at least one priority
> level in the node tree (that would bring the queue empty performance
> more in line with the old implementation), but this works and is *so*
> much better than what we had, especially for the common case of a
> single priority in use, that further refinements can be in follow on
> patches.

Nice work! Yeah I think if you cache a last unused entry, that
should mostly solve the empty queue regression.

I would imagine most users won't have huge queues, so the
empty case should be important too.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/