Julian Elischer | 1 Oct 06:22 2007

Re: Kernel thread stack usage

Alexander Motin wrote:
> Hi.
> 
> As known in netgraph susbystem information passing from one node to 
> another by direct function calls without queueing. It gives performance 
> bonuses, but it also gives permanent stack overflow risk on complicated 
> graphs. Netgraph is still have a queues and able to use them when asked, 
> but now queueing is a flag which should be controlled by sending node. I 
> think it would be good to implement some algorithm which could monitor 
> stack usage on each call and enforce queueing when stack usage become 
> critical.
> 
> The question is: is there correct way to somehow get current kernel 
> thread stack usage or just a stack base address?
> 

I've thought about this quite a bit over the years.

On possibility is a stack usage meter (which once did work out)
and another is to have a 'hop count (or recursion count)
added to the arguments passed around with the data.
 The nodes would have to cooperate with this scheme.

The counter could be in the 'item' or an explicit argument.
The 'recursion depth' counter may or may not be the same thing as a 'hop count'
that could be kept in the mbuf.

it is possible both make sense

two mbuf counters. one oncremented whenever there is am mbuf handoff
(Continue reading)

Alexander Motin | 1 Oct 10:57 2007
Picon

Re: Kernel thread stack usage


Julian Elischer wrote:
> two mbuf counters. one oncremented whenever there is am mbuf handoff
> that doesn't involve queueing, and is cleared to 0 whenever queueing is
> invoked,
> and one that is continually incremented until the packet leaves the
> machine..
> 
> one to stop packets permanently circulating around a machine and one for
> stack protection..

Using counter in item will not help in case where packet leaves
netgraph, but will come back later. Also item can be destroyed and
recreated by some nodes like ng_ppp.

And even except this counter will not be a best solution as for example
ng_tee node have significantly lower stack usage then previous version
of ng_bpf or tcp stack call from ksocket. ng_tee node can handle a
hundres, while previous ng_bpf would die after 25 calls.

--
Alexander Motin
Hans Petter Selasky | 2 Oct 21:02 2007
Picon

Re: Request for feedback on common data backstore in the kernel

On Thursday 27 September 2007, Scott Long wrote:
> Hans Petter Selasky wrote:

> >
> > I'm thinking about putting some wrappers around the "bus_dmamap_load()"
> > function like:
> >
> > void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf,
> >   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
> >
> > void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf,
> >   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
> >
> > But I haven't figured out all the details yet. The "usbd_xxx_load()"
> > functions should automagically figure out what is best to do and it won't
> > be more than a few lines of code.
>
> Can you describe what these two wrappers are supposed to do? 

Basically these wrappers will setup the DMA address for the USB HC driver. If 
they need to copy data they will copy data.

> Are you expecting bus_dmamap_load() to operate synchronously?

Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a 
thread context.

--HPS
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
(Continue reading)

Scott Long | 3 Oct 01:39 2007

Re: Request for feedback on common data backstore in the kernel

Hans Petter Selasky wrote:
> On Thursday 27 September 2007, Scott Long wrote:
>> Hans Petter Selasky wrote:
> 
>>> I'm thinking about putting some wrappers around the "bus_dmamap_load()"
>>> function like:
>>>
>>> void usbd_rx_buf_load(struct usbd_xfer *xfer, void *buf,
>>>   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
>>>
>>> void usbd_tx_buf_load(struct usbd_xfer *xfer, void *buf,
>>>   uint32_t framebuffer_offset, uint32_t framebuffer_index, uint32_t len);
>>>
>>> But I haven't figured out all the details yet. The "usbd_xxx_load()"
>>> functions should automagically figure out what is best to do and it won't
>>> be more than a few lines of code.
>> Can you describe what these two wrappers are supposed to do? 
> 
> Basically these wrappers will setup the DMA address for the USB HC driver. If 
> they need to copy data they will copy data.

Bouncing/copying is built into the busdma API.  If there's a reason to 
duplicate that logic in USB, please let me know.

> 
>> Are you expecting bus_dmamap_load() to operate synchronously?
> 
> Yes. I assume that "bus_dmamap_load()" can sleep and consequently needs a 
> thread context.

(Continue reading)

Jeff Roberson | 8 Oct 23:40 2007
Picon

Abolishing sleeps in issignal()

During the work on thread lock I observed that there is a significant 
amount of locking involved in our signal paths right now.  And these locks 
also show up contended in many workloads.  Furthermore, requiring a DEF 
mutex complicates sleep queues by forcing them to drop the spinlock to 
check for signals and then check for races.

The current issignal() code will actually msleep in the case of a 
stopevent() requested by the debugger.  This is fine for signals that 
would normally abort the sleep anyway, but SIGSTOP actually leaves the 
thread on the sleep queue and tries to resume the sleep after the stop has 
cleared.  So SIGSTOP combined with a stopevent() actually breaks because 
the stopevent() removes the thread from the sleep queue.  I'm not certain 
what the failure mode is currently, but I'm certain that it's wrong.

What I'd like to do is stop sleeping in issignal() all together.  For 
regular restartable syscalls this would mean failing back out to ast() 
where we'd then handle the signals including SIGSTOP.  After SIGCONT we'd 
then restart the syscall.  For non-restartable syscalls we could have a 
special issignal variant that is called when msleep/cv_timedwait_sig 
return interrupted that would check for SIGSTOP/debugger events and sleep 
within a loop retrying the operation.  This would preserve the behavior of 
debugging events and SIGSTOP not aborting non-restartable syscalls as they 
do now.

Once we have moved the location of the sleeps it will be possible to check 
for signals using a spinlock without dropping the sleep queue lock in 
sleepq_catch_signals().

What I'd like from readers on arch <at>  is for you to consider if there are 
other cases than non-restartable syscalls that will break if 
(Continue reading)

Alfred Perlstein | 8 Oct 23:50 2007
Picon

Re: Abolishing sleeps in issignal()

* Jeff Roberson <jroberson <at> chesapeake.net> [071008 14:39] wrote:
> 
> What I'd like from readers on arch <at>  is for you to consider if there are 
> other cases than non-restartable syscalls that will break if 
> msleep/sleepqs return EINTR from SIGSTOP and debug events.  Also, is there 
> an authoritative list of non-restartable syscalls anywhere?  It's just 
> those involving timevals right?  nanosleep/poll/select/kqueue.. others?
> 
> I intend to do this work for 8.0 and hopefully very early on so we have 
> plenty of time to shake out bugs as this signal code tends to be very 
> delicate.
> 

Is there precident for this work from other OSes, Linux, Solaris
that shows moving to this model works?

--

-- 
- Alfred Perlstein
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"

Jeff Roberson | 9 Oct 01:06 2007
Picon

Re: Abolishing sleeps in issignal()

On Mon, 8 Oct 2007, Alfred Perlstein wrote:

> * Jeff Roberson <jroberson <at> chesapeake.net> [071008 14:39] wrote:
>>
>> What I'd like from readers on arch <at>  is for you to consider if there are
>> other cases than non-restartable syscalls that will break if
>> msleep/sleepqs return EINTR from SIGSTOP and debug events.  Also, is there
>> an authoritative list of non-restartable syscalls anywhere?  It's just
>> those involving timevals right?  nanosleep/poll/select/kqueue.. others?
>>
>> I intend to do this work for 8.0 and hopefully very early on so we have
>> plenty of time to shake out bugs as this signal code tends to be very
>> delicate.
>>
>
> Is there precident for this work from other OSes, Linux, Solaris
> that shows moving to this model works?

I forgot to mention that.  These two both use this model.  Linux sets up
a complicated syscall restart state so that the normal syscal restart 
mechanism can be used.  I didn't fully understand what solaris does but 
they don't sleep in issignal.  They do it later as well.

Jeff.

>
> -- 
> - Alfred Perlstein
>
_______________________________________________
(Continue reading)

LI Xin | 9 Oct 02:43 2007
Picon

Why we optimize by time by default for < -O2 case?

Hi,

I wonder why we want to optimize by time by default and not by space by
default for the system compiler, does the reasoning still hold true?
The commit log said:

  Modified files:
    contrib/gcc          toplev.c
  Log:
  Clarify revision 1.14:
  Gcc 3.1's -O0 and -O1 actually optimized alignment for space, but we feel
  it should optimize alignment for time like Gcc 2.95 used to.  Optimization
  for space should give 1-byte alignment on i386's, but doesn't quite.

  Revision  Changes    Path
  1.15      +0 -0      src/contrib/gcc/toplev.c

Cheers,
--

-- 
Xin LI <delphij <at> delphij.net>	http://www.delphij.net/
FreeBSD - The Power to Serve!

Daniel Eischen | 9 Oct 03:09 2007
Picon

Re: Abolishing sleeps in issignal()

On Mon, 8 Oct 2007, Jeff Roberson wrote:

> During the work on thread lock I observed that there is a significant amount 
> of locking involved in our signal paths right now.  And these locks also show 
> up contended in many workloads.  Furthermore, requiring a DEF mutex 
> complicates sleep queues by forcing them to drop the spinlock to check for 
> signals and then check for races.
>
> The current issignal() code will actually msleep in the case of a stopevent() 
> requested by the debugger.  This is fine for signals that would normally 
> abort the sleep anyway, but SIGSTOP actually leaves the thread on the sleep 
> queue and tries to resume the sleep after the stop has cleared.  So SIGSTOP 
> combined with a stopevent() actually breaks because the stopevent() removes 
> the thread from the sleep queue.  I'm not certain what the failure mode is 
> currently, but I'm certain that it's wrong.
>
> What I'd like to do is stop sleeping in issignal() all together.  For regular 
> restartable syscalls this would mean failing back out to ast() where we'd 
> then handle the signals including SIGSTOP.  After SIGCONT we'd then restart 
> the syscall.  For non-restartable syscalls we could have a special issignal 
> variant that is called when msleep/cv_timedwait_sig return interrupted that 
> would check for SIGSTOP/debugger events and sleep within a loop retrying the 
> operation.  This would preserve the behavior of debugging events and SIGSTOP 
> not aborting non-restartable syscalls as they do now.
>
> Once we have moved the location of the sleeps it will be possible to check 
> for signals using a spinlock without dropping the sleep queue lock in 
> sleepq_catch_signals().
>
> What I'd like from readers on arch <at>  is for you to consider if there are other 
(Continue reading)

Mike Karels | 9 Oct 04:03 2007
Picon

Re: Abolishing sleeps in issignal()

> What I'd like from readers on arch <at>  is for you to consider if there are 
> other cases than non-restartable syscalls that will break if 
> msleep/sleepqs return EINTR from SIGSTOP and debug events.  Also, is there 
> an authoritative list of non-restartable syscalls anywhere?  It's just 
> those involving timevals right?  nanosleep/poll/select/kqueue.. others?

Don't forget about siginterrupt, which can make specified syscalls
interrupt read/read etc.

		Mike
_______________________________________________
freebsd-arch <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "freebsd-arch-unsubscribe <at> freebsd.org"


Gmane