pcp
[Top] [All Lists]

Re: multithreading bottleneck: pdubuf.c

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: multithreading bottleneck: pdubuf.c
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 03 Mar 2015 16:13:37 -0500
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <54F61811.3090400@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Wed, 04 Mar 2015 07:22:41 +1100")
References: <20150302015436.GB21203@xxxxxxxxxx> <54F61811.3090400@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
kenj wrote:

> [...]
> A bit of history might help explain the status quo and guide
> reimplementation ...

Thanks a lot, such info is awesome.

> + the pdu buffers are page size aligned for a reason ... these are
> used for direct I/O calls, and some operating systems are able to
> expedite the handling of I/O for page aligned buffers (avoiding the
> need to copy at all in some cases) [...]

OK, I see the valloc(), but not direct I/O (in the sense of fcntl
O_DIRECT or mmap), so there's going to be some user->kernel buffer
copying regardless of alignment.

> [...]
> + page alignment means that the buffers should be sized in units of
> multiple pages also [...]

Wouldn't valloc() do that, without rounding-up on our side?

> [...]
> + because the range of PDU sizes was small and there was no
> multithreading and buffers did not remain pinned for long, the
> number of buffers in the pool was expected to be small

Yeah - I recall seeing some dozens of entries at most in older
debugging sessions on singlethreaded pcp clients.

> [...]
> Hope the history helps.

Absolutely!

> I encourage Frank to investigate here, but before committing to a
> new regime I'd hope to to see some empirical evidence of new vs old
> performance.

Right - some early results were posted on the thread a few days back,
looking promising.  Can you suggest some specific benchmarking
scenarios expected to stress this area?


- FChE

<Prev in Thread] Current Thread [Next in Thread>