Re: pool_debug

2017-01-24 Thread Ted Unangst
Martin Pieuchot wrote: > I'd like to force a yield() for every pool_get(9) using PR_WAITOK, just > like we do with malloc(9), in order to ensure that the NET_LOCK() is not > held across context switches. > > ok? Is there an assertwaitok() missing? Indeed there is. I think that should be added, l

Re: pool_debug

2017-01-24 Thread Martin Pieuchot
On 24/01/17(Tue) 08:06, Christiano F. Haesbaert wrote: > Not sure I get it, the rwlock when is not released when you yield()). So > this will in fact context switch holding the rwlock for every pool_get(). > Did I miss another a change ? That's true. I'd like to know when that happens and where.

Re: pool_debug

2017-01-24 Thread Christiano F. Haesbaert
On Tue, 24 Jan 2017 at 09:14, Martin Pieuchot wrote: > On 24/01/17(Tue) 08:06, Christiano F. Haesbaert wrote: > > > Not sure I get it, the rwlock when is not released when you yield()). So > > > this will in fact context switch holding the rwlock for every pool_get(). > > > Did I miss another a c

Re: pool_debug

2017-01-24 Thread Christiano F. Haesbaert
l *pp, int flags) > > } > > mtx_leave(&pp->pr_mtx); > > > > - if (slowdown && ISSET(flags, PR_WAITOK)) > > + if ((slowdown || pool_debug == 2) && ISSET(flags, PR_WAITOK)) > > yield(); > > > > if (v == NULL) { > > > >

Re: pool_debug

2017-01-23 Thread David Gwynne
4 Jan 2017 06:29:09 - > @@ -513,7 +513,7 @@ pool_get(struct pool *pp, int flags) > } > mtx_leave(&pp->pr_mtx); > > - if (slowdown && ISSET(flags, PR_WAITOK)) > + if ((slowdown || pool_debug == 2) && ISSET(flags, PR_WAITOK)) > yield(); > > if (v == NULL) { >

pool_debug

2017-01-23 Thread Martin Pieuchot
- if (slowdown && ISSET(flags, PR_WAITOK)) + if ((slowdown || pool_debug == 2) && ISSET(flags, PR_WAITOK)) yield(); if (v == NULL) {

Re: pool_debug and network throughput on Alix

2013-01-22 Thread Mattieu Baptiste
ame, or it's something odd with my setup. > I'm testing by running tcpbench on two other machines, with the > traffic routed through the alix, ethernet->ethernet, not natted. > > With pool_debug enabled (sysctl kern.pool_debug=1) as is default > in -current, I'm see

pool_debug and network throughput on Alix

2013-01-22 Thread Stuart Henderson
Seeing some odd behaviour on an alix firewall and wondering if other people see the same, or it's something odd with my setup. I'm testing by running tcpbench on two other machines, with the traffic routed through the alix, ethernet->ethernet, not natted. With pool_debug en

Re: pool_debug is good, but also bad

2011-04-04 Thread Thordur Bjornsson
On Sun, Apr 03, 2011 at 06:38:51PM -0600, Theo de Raadt wrote: > based on a conversation at the bar. > > POOL_DEBUG is expensive. But we really want it because it finds bugs > before they hurt us. The solution to this is to make it simpler to > turn off. > > This diff s

Re: pool_debug is good, but also bad

2011-04-04 Thread Mark Kettenis
> Date: Sun, 03 Apr 2011 18:38:51 -0600 > From: Theo de Raadt > > based on a conversation at the bar. > > POOL_DEBUG is expensive. But we really want it because it finds bugs > before they hurt us. The solution to this is to make it simpler to > turn off. > > Th

Re: pool_debug is good, but also bad

2011-04-03 Thread Damien Miller
On Sun, 3 Apr 2011, Theo de Raadt wrote: > based on a conversation at the bar. > > POOL_DEBUG is expensive. But we really want it because it finds bugs > before they hurt us. The solution to this is to make it simpler to > turn off. Is it expensive because it tests every pool

pool_debug is good, but also bad

2011-04-03 Thread Theo de Raadt
based on a conversation at the bar. POOL_DEBUG is expensive. But we really want it because it finds bugs before they hurt us. The solution to this is to make it simpler to turn off. This diff starts the kernel with pool debug on, but allows it to be turned off with sysctl kern.pool_debug=0