On 22.8.2016. 8:20, David Gwynne wrote:
>
>> On 22 Aug 2016, at 03:36, Hrvoje Popovski wrote:
>>
>> On 13.8.2016. 10:59, Claudio Jeker wrote:
>>> This diff refactors the uio to mbuf code to make use of bigger buffers (up
>>> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls i
> On 22 Aug 2016, at 03:36, Hrvoje Popovski wrote:
>
> On 13.8.2016. 10:59, Claudio Jeker wrote:
>> This diff refactors the uio to mbuf code to make use of bigger buffers (up
>> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in
>> the same function. I see no point in not
On 13.8.2016. 10:59, Claudio Jeker wrote:
> This diff refactors the uio to mbuf code to make use of bigger buffers (up
> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in
> the same function. I see no point in not waiting for a cluster and instead
> chain lots of mbufs toget
On Thu, Aug 18, 2016 at 12:49:07AM +0200, Alexander Bluhm wrote:
> On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote:
> > On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote:
> > > As I understand, we are hitting the global mbuf cluster limit. I
> > > don't see how a change
> On 18 Aug 2016, at 08:49, Alexander Bluhm wrote:
>
> On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote:
>> On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote:
>>> As I understand, we are hitting the global mbuf cluster limit. I
>>> don't see how a changed pool wakeup
On Wed, Aug 17, 2016 at 09:21:21PM +0200, Claudio Jeker wrote:
> On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote:
> > As I understand, we are hitting the global mbuf cluster limit. I
> > don't see how a changed pool wakeup policy could fix this hang.
> >
>
> Choose your poision.
On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote:
> On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote:
> > the reason is that pools now keep track of things that are sleeping
> > for memory and will give them an item BEFORE waking them up.
> > previously i believe they wer
On Wed, Aug 17, 2016 at 02:29:49PM +0200, Alexander Bluhm wrote:
> On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote:
> > the reason is that pools now keep track of things that are sleeping
> > for memory and will give them an item BEFORE waking them up.
> > previously i believe they wer
On Wed, Aug 17, 2016 at 10:18:26PM +1000, David Gwynne wrote:
> the reason is that pools now keep track of things that are sleeping
> for memory and will give them an item BEFORE waking them up.
> previously i believe they were woken up to try and get an item,
> which could fail as you described be
On Wed, Aug 17, 2016 at 01:43:00PM +0200, Alexander Bluhm wrote:
> On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote:
> > to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in
> > the same function. I see no point in not waiting for a cluster and instead
> > chain lo
On Sat, Aug 13, 2016 at 10:59:30AM +0200, Claudio Jeker wrote:
> to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in
> the same function. I see no point in not waiting for a cluster and instead
> chain lots of mbufs together as a consequence.
The M_WAIT reverts this bugfix:
> On 17 Aug 2016, at 5:23 PM, Simon Mages wrote:
>
> Hi,
>
> this diff works for me.
>
> I tested TCP and Unix Domain Sockets. I did no performance tests though.
>
> I like this version better then the one i was working with, it really
> is easier to read.
cool. id like to see it go in.
ok
Hi,
this diff works for me.
I tested TCP and Unix Domain Sockets. I did no performance tests though.
I like this version better then the one i was working with, it really
is easier to read.
For completeness follows the diff i was using:
Index: kern/uipc_socket.c
===
This diff refactors the uio to mbuf code to make use of bigger buffers (up
to 64k) and also switches the MCLGET to use M_WAIT like the MGET calls in
the same function. I see no point in not waiting for a cluster and instead
chain lots of mbufs together as a consequence.
This makes in my opinion th
14 matches
Mail list logo