On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
wrote:
> Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
> > Is this FreeBSD 9.x or HEAD?
>
> I found the problem and developed the patch on 9.1.
>
> Can you please test this more 'beautiful' patch.
Its similar to yours but also dela
Also do not forget to rebuild pfctl so that statistics are shown correctly.
On Sat, Mar 9, 2013 at 1:14 PM, Ermal Luçi wrote:
>
>
>
> On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz <
> veg...@tuxpowered.net> wrote:
>
>> Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
>> > Is t
Dnia sobota, 9 marca 2013 o 13:14:16 Ermal Luçi napisał(a):
> On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
>
> wrote:
> > Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
> > > Is this FreeBSD 9.x or HEAD?
> >
> > I found the problem and developed the patch on 9.1.
> >
> Can y
On Sat, Mar 9, 2013 at 2:37 PM, Kajetan Staszkiewicz
wrote:
> Dnia sobota, 9 marca 2013 o 13:14:16 Ermal Luçi napisał(a):
> > On Fri, Mar 8, 2013 at 9:51 PM, Kajetan Staszkiewicz
> >
> > wrote:
> > > Dnia piątek, 8 marca 2013 o 21:11:43 Ermal Luçi napisał(a):
> > > > Is this FreeBSD 9.x or HEAD?
>
Dnia sobota, 9 marca 2013 o 16:11:56 napisałeś:
> > > Though the src node removal option through pfctl -K does a lot of job
> > > to cleanup things
> > > Still need to undertand why it takes so much time for you to loop
> > > through 500K states.
> >
> > That is because the loop will not be calle
Garrett Wollman wrote:
> < said:
>
> > The cached replies are copies of the mbuf list done via m_copym().
> > As such, the clusters in these replies won't be free'd (ref cnt ->
> > 0)
> > until the cache is trimmed (nfsrv_trimcache() gets called after the
> > TCP layer has received an ACK for rec
Garrett Wollman wrote:
> < said:
>
> > If reducing the size to 4K doesn't fix the problem, you might want
> > to
> > consider shrinking the tunable vfs.nfsd.tcphighwater and suffering
> > the increased CPU overhead (and some increased mutex contention) of
> > calling nfsrv_trimcache() more freque
<
said:
> I suspect this indicates that it isn't mutex contention, since the
> threads would block waiting for the mutex for that case, I think?
No, because our mutexes are adaptive, so each thread spins for a while
before blocking. With the current implementation, all of them end up
doing this
<
said:
> around the highwater mark basically indicates this is working. If it wasn't
> throwing away replies where the receipt has been ack'd at the TCP
> level, the cache would grow very large, since they would only be
> discarded after a loonnngg timeout (12hours unless you've changes
> NFSRVC
In article <20795.29370.194678.963...@hergotha.csail.mit.edu>, I wrote:
>< said:
>> I've thought about this. My concern is that the separate thread might
>> not keep up with the trimming demand. If that occurred, the cache would
>> grow veryyy laarrggge, with effects like running out of mbuf cluste
On Mar 7, 2013, at 9:42 PM, John-Mark Gurney wrote:
> Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 +0100:
>>> Adding interface address is handled via atomically deleting old prefix and
>>> adding interface one.
>>
>> This brings up a long standing sore point of our routing c
On 09.03.2013 23:17, Nikolay Denev wrote:
On Mar 7, 2013, at 9:42 PM, John-Mark Gurney wrote:
Andre Oppermann wrote this message on Thu, Mar 07, 2013 at 08:39 +0100:
Adding interface address is handled via atomically deleting old prefix and
adding interface one.
This brings up a long standi
Old Synopsis: user-mode netgraph node hangs when replying to control message
New Synopsis: [libnetgraph] [patch] user-mode netgraph node hangs when replying
to control message
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Mar
Garett Wollman wrote:
> In article <20795.29370.194678.963...@hergotha.csail.mit.edu>, I
> wrote:
> >< > said:
> >> I've thought about this. My concern is that the separate thread
> >> might
> >> not keep up with the trimming demand. If that occurred, the cache
> >> would
> >> grow veryyy laarrggge
Garrett Wollman wrote:
> < said:
>
> > around the highwater mark basically indicates this is working. If it
> > wasn't
> > throwing away replies where the receipt has been ack'd at the TCP
> > level, the cache would grow very large, since they would only be
> > discarded after a loonnngg timeout
Garrett Wollman wrote:
> < said:
>
> > I suspect this indicates that it isn't mutex contention, since the
> > threads would block waiting for the mutex for that case, I think?
>
> No, because our mutexes are adaptive, so each thread spins for a while
> before blocking. With the current implement
Old Synopsis: panic: IPsec + enc(4); device name clash with CAM
New Synopsis: [ipsec] [enc] [patch] panic: IPsec + enc(4); device name clash
with CAM
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Responsible-Changed-When: Sun Mar 10 04:52:34 UTC 2013
Respo
Old Synopsis: process of 'ifconfig gif0 create hangs' when if_gif_load exists
in /etc/loader.conf and 'device gif' exists in kernel config.
New Synopsis: [gif] process of 'ifconfig gif0 create hangs' when if_gif_load
exists in /etc/loader.conf and 'device gif' exists in kernel config.
Responsibl
< said:
> Yes, in the past the code was in this form, it should work fine Garrett,
> just make sure
> the 4K pool is large enough.
[Andre Oppermann's patch:]
>> if (adapter->max_frame_size <= 2048)
adapter-> rx_mbuf_sz = MCLBYTES;
>> - else if (adapter->max_frame_size <= 4096)
>> + el
19 matches
Mail list logo
