poll()/select()

Konstantin Prokazoff kprokazov at svr.kiev.ua
Mon Nov 21 13:01:15 GMT 2005


Thanks for comment,

    I think, after kernel inspection, problem (maybe) in preemption. While
syscall to poll or select holds sellock, and if another thread (process)
tries to syscall or we have taken interrupt (where handler use
selrecord/selwakeup too), kernel will deadlock.
    I have this situation cause to INTR_FAST interrupt handler in device
driver for Digium's PCI board, which provides 4 T1/E1 interfaces. Problem
100% repetitive.
    Another way to avoid such deadlock - provide different kthread/ithreads
for select/poll mechanism.

Best regards,
        Konstantin Prokazoff
Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
Official business-partner & DevConnect member of Avaya Inc.
Regional development & support center of Digium Inc.
Tel. +38 044 244 1181, ext. 1038
Fax. +38 044 234 0455

----- Original Message ----- 
From: <ray at redshift.com>
To: "Konstantin Prokazoff" <kprokazov at svr.kiev.ua>;
<freebsd-hackers at freebsd.org>
Sent: Monday, November 21, 2005 2:42 PM
Subject: Re: poll()/select()


> At 10:29 AM 11/21/2005 +0200, Konstantin Prokazoff wrote:
> | Welcome everybody,
> |
> |     have a strange issue under 5.x/6.x (checked).
> |     When using a poll()/select() mechanism, which in kernel based on
> | selrecord/selwakeup (pollscan, kern_select) functions, we have deadlock
on
> | sellock mutex on heavy load (recursive lock on non-recursive mutex).
Have
> | anyone seen this? Deadlock can be reached only if kernel w'be compiled
with
> | debugger, because in different case system locks, your can't login, etc.
> | Maybe one path to resolve - change behavour of sched_lock & sellock
mutexes
> | block/unblock order.
> |     Thnx in advance & for comments.
> |
> | Best regards,
> |         Konstantin Prokazoff
> | Center Of Excellence, S_V_R Ltd., Kyiv HQs, Ukraine
> | Official business-partner & DevConnect member of Avaya Inc.
> | Regional development & support center of Digium Inc.
> | Tel. +38 044 244 1181, ext. 1038
> | Fax. +38 044 234 0455
>
> The only thing I can add is that a sys admin friend of mine did try using
the
> poll/select to increase performance and had to finally abandon it due to
> instability problems under load.
>
> I've never tried it first hand myself.  Not sure if that helps you.
>
> Ray
>
>
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"



More information about the freebsd-hackers mailing list