On Fri, May 03, 2019 at 03:37:11PM -0400, Garrett Wollman wrote:
> < said:
>
> > On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
> >> Does anyone have an easy patch to keep mce(4) from trying to use 9k
> >> jumbo mbuf clusters? I think I went down this road once before but
> >>
<
said:
> On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
>> Does anyone have an easy patch to keep mce(4) from trying to use 9k
>> jumbo mbuf clusters? I think I went down this road once before but
>> the fix wasn't as obvious as it is for the Intel drivers. (I assume
>> the h
On Fri, May 03, 2019 at 12:55:54PM -0400, Garrett Wollman wrote:
> Does anyone have an easy patch to keep mce(4) from trying to use 9k
> jumbo mbuf clusters? I think I went down this road once before but
> the fix wasn't as obvious as it is for the Intel drivers. (I assume
> the hardware is not s
Does anyone have an easy patch to keep mce(4) from trying to use 9k
jumbo mbuf clusters? I think I went down this road once before but
the fix wasn't as obvious as it is for the Intel drivers. (I assume
the hardware is not so broken that it requires packets to be stored in
contiguous physical mem
Adrian Chadd wrote:
>John-Mark Gurney wrote:
[stuff snipped]
>>
>> Drivers need to be fixed to use 4k pages instead of cluster. I really hope
>> no one is using a card that can't do 4k pages, or if they are, then they
>> should get a real card that can do scatter/gather on 4k pages for jumbo
>> fr
In article <20180729011153.gd2...@funkthat.com> j...@funkthat.com
writes:
>And I know you know the problem is that over time memory is fragmented,
>so if suddenly you need more jumbo frames than you already have, you're
>SOL...
This problem instantly disappears if you preallocate several gigabyte
lem:
> > > https://reviews.freebsd.org/D11560#239462
> > > I???m curious whether that has been confirmed.
> > >
> > > Is anyone working on the pathological case with 9k jumbo clusters in the
> > > physical memory allocator? There was an interesting discus
>
> > Is anyone working on the pathological case with 9k jumbo clusters in the
> > physical memory allocator? There was an interesting discussion started a
> > few years ago but I???m not sure what ever came of it:
> > http://docs.freebsd.org/cgi/mid.cgi?21225.20047.94738
ml
>
> This comment suggests the 16k pool does not have the fragmentation problem:
> https://reviews.freebsd.org/D11560#239462
> I???m curious whether that has been confirmed.
>
> Is anyone working on the pathological case with 9k jumbo clusters in the
> physical memory all
In article
r...@ixsystems.com writes:
>I have seen some work in the direction of avoiding larger than page size
>jumbo clusters in 12-CURRENT. Many existing drivers avoid the 9k cluster
>size already. The code for larger cluster sizes in iflib is #ifdef'd out
>so it maxes out at the page size j
:
https://reviews.freebsd.org/D11560#239462
I’m curious whether that has been confirmed.
Is anyone working on the pathological case with 9k jumbo clusters in the
physical memory allocator? There was an interesting discussion started a
few years ago but I’m not sure what ever came of it:
http
rs out of packet secondary zone in use
(current/cache)
0/873/873/6127794 4k (page size) jumbo clusters in use
(current/cache/total/max)
16383/21517/37900/1815641 9k jumbo clusters in use
(current/cache/total/max)
0/0/0/1021298 16k jumbo clusters in us
0/873/873/6127794 4k (page size) jumbo clusters in use
(current/cache/total/max)
16383/21517/37900/1815641 9k jumbo clusters in use
(current/cache/total/max)
0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max)
188407K/222004K/410411K by
tat -m shows:
>> 32881/33854/66735 mbufs in use (current/cache/total)
>> 16370/8198/24568/12255588 mbuf clusters in use (current/cache/total/max)
>> 16370/4807 mbuf+clusters out of packet secondary zone in use
>> (current/cache)
>> 0/873/873/6127794 4k (page size) jumb
packet secondary zone in use
(current/cache)
0/873/873/6127794 4k (page size) jumbo clusters in use
(current/cache/total/max)
16383/21517/37900/1815641 9k jumbo clusters in use
(current/cache/total/max)
0/0/0/1021298 16k jumbo clusters in use (current/cache/total/max)
188407K/222004K/410411K bytes
/mbuf+clusters)
0/0/0 requests for jumbo clusters delayed (4k/9k/16k)
0/101414306/0 requests for jumbo clusters denied (4k/9k/16k)
0 requests for sfbufs denied
0 requests for sfbufs delayed
0 requests for I/O initiated by sendfile
9k jumbo clusters max is too big, but looks like system cannot
16 matches
Mail list logo
