On Thu, Nov 16, 2017 at 08:13:39PM +0100, Gregor Best wrote:
> On Thu, Nov 16, 2017 at 11:13:04AM +1000, David Gwynne wrote:
> >
> > > On 16 Nov 2017, at 7:23 am, Gregor Best wrote:
> > >
> > > Hi,
> > >
> > > On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
>
On Thu, Nov 16, 2017 at 11:13:04AM +1000, David Gwynne wrote:
>
> > On 16 Nov 2017, at 7:23 am, Gregor Best wrote:
> >
> > Hi,
> >
> > On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
> >> [...]
> >> pools maintain count of how many times they failed to provide
> On 16 Nov 2017, at 7:23 am, Gregor Best wrote:
>
> Hi,
>
> On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
>> [...]
>> pools maintain count of how many times they failed to provide an
>> allocation. you can watch this with vmstat -m or systat pool.
>>
Hi,
On Mon, Nov 13, 2017 at 01:47:01PM +1000, David Gwynne wrote:
> [...]
> pools maintain count of how many times they failed to provide an
> allocation. you can watch this with vmstat -m or systat pool.
> however, we could use that to populate mb_drops too.
> [...]
That's certainly smarter
On 13/11/17(Mon) 13:47, David Gwynne wrote:
> On Sun, Nov 12, 2017 at 11:23:31PM +0100, Gregor Best wrote:
> > Hi Martin,
> >
> > On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote:
> > > [...]
> > > It does, some comments below.
> > > [...]
> >
> > Wonderful.
> >
> > > [...]
> > >
On Sun, Nov 12, 2017 at 11:23:31PM +0100, Gregor Best wrote:
> Hi Martin,
>
> On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote:
> > [...]
> > It does, some comments below.
> > [...]
>
> Wonderful.
>
> > [...]
> > This would be an approximation because it might happen that after
>
Hi Martin,
On Sun, Nov 12, 2017 at 03:40:59PM +0100, Martin Pieuchot wrote:
> [...]
> It does, some comments below.
> [...]
Wonderful.
> [...]
> This would be an approximation because it might happen that after
> returning NULL the second pool_get(9) won't sleep. However I think
> it's the way
On 11/11/17(Sat) 13:05, Gregor Best wrote:
> Hi people,
>
> while reading around in /sys/kern/uipc_mbuf.c to try to track down a
> problem with my iwm(4) that seems to correlate with mbuf allocation
> failures, I noticed that the MBSTAT_DROPS counter and its friends
> MBSTAT_{WAIT,DRAIN} don't
Hi people,
while reading around in /sys/kern/uipc_mbuf.c to try to track down a
problem with my iwm(4) that seems to correlate with mbuf allocation
failures, I noticed that the MBSTAT_DROPS counter and its friends
MBSTAT_{WAIT,DRAIN} don't seem to get increased anywhere in /sys.
Does the patch