lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Tue, 12 Jun 2018 13:19:28 -0400 (EDT)
From:   Mikulas Patocka <mpatocka@...hat.com>
To:     Alan Stern <stern@...land.harvard.edu>
cc:     Ming Lei <ming.lei@...hat.com>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        USB list <linux-usb@...r.kernel.org>,
        Kernel development list <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] usb: don't offload isochronous urb completions to
 ksoftirq



On Tue, 12 Jun 2018, Alan Stern wrote:

> On Tue, 12 Jun 2018, Mikulas Patocka wrote:
> 
> > > How about making the softirq thread's priority adjustable?
> > 
> > But you would have to argue with softirq maintainers about it - and you 
> > say that you don't have time for that.
> 
> But maybe _you_ do...

ksoftirqd has priority 0 - it is not suitable for real-time tasks, such as 
audio.

In my opinion, it is much easier to fix this in the ehci driver (by not 
offloading isochronous completions), than to design a new 
real-time-capable ksoftirqd.

> > > As for coordinating with the softirq maintainers -- whether I want to 
> > > or not isn't the issue.  Right now I don't have _time_ to do it.
> > > 
> > > Alan Stern
> > 
> > I am wondering - whats the purpose of that patch 
> > 428aac8a81058e2303677a8fbf26670229e51d3a at all? The patch shows some 
> > performance difference, but they are minor, about 1%.
> > 
> > If you want to call the urb callback as soon as possible - why don't you 
> > just call it? Why do you need to offload the callback to a softirq thread?
> 
> Please read the Changelog entry for commit 94dfd7edfd5c.  Basically the 
> idea was to reduce overall latency by not doing as much work in an 
> interrupt handler.
> 
> Alan Stern

snd_complete_urb is doing nothing but submitting the same urb again. Is 
resubmitting the urb really causing so much latency that you can't do it 
in the interrupt handler?

Mikulas

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ