On Sat, May 04, 2013 at 07:39:57AM -0400, Peter Hurley wrote:
> On 05/04/2013 07:15 AM, Johan Hovold wrote:
> > On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote:
> >> 04.05.2013 00:34, Greg KH пишет:
> >>> On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
> 03.05.2013 2
On 05/04/2013 07:15 AM, Johan Hovold wrote:
On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote:
04.05.2013 00:34, Greg KH пишет:
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
03.05.2013 21:16, Greg KH пишет:
[...]
There's no guarantee as to how long select or an i
04.05.2013 15:15, Johan Hovold пишет:
The query takes longer than the transmit at decent baudrates (>=38k)
and under the assumption that flow control isn't causing any delays.
But you do have a point, and I have been meaning to look into whether
the added overhead of checking the hardware buffer
On Sat, May 04, 2013 at 01:50:42AM +0400, Stas Sergeev wrote:
> 04.05.2013 00:34, Greg KH пишет:
> > On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
> >> 03.05.2013 21:16, Greg KH пишет:
[...]
> >>> There's no guarantee as to how long select or an ioctl will take, and
> >>> now that
04.05.2013 00:34, Greg KH пишет:
Don't call select for every character :)
OK, let me draw an approximate workflow of the
setup in question.
Lets say we have 3 tty devices, A, B and C.
A and B are blazingly fast, while C is a casual usb-serial
chip.
The app must establish a bidirectional relay be
04.05.2013 00:34, Greg KH пишет:
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the se
On Fri, May 03, 2013 at 10:27:18PM +0400, Stas Sergeev wrote:
> 03.05.2013 21:16, Greg KH пишет:
>
> >Sounds like an application is doing a foolish thing and should stop it.
> Its not.
> The app is quering only for _input_ (specifying only read fds
> to select). But the select() in linux is implem
03.05.2013 21:16, Greg KH пишет:
Sounds like an application is doing a foolish thing and should stop it.
Its not.
The app is quering only for _input_ (specifying only read fds
to select). But the select() in linux is implemented the way that
even when it polls for input, it will still call tty_
03.05.2013 20:52, Greg KH пишет:
What exactly is the "problem" being seen?
OK, the problem is that while select() "stalls", the entire
output queue is transmitted, and when the app writes
more, there is already a big pause.
In fact, the app calls select() before writing every char,
so then the d
On Fri, May 03, 2013 at 10:05:55PM +0400, Stas Sergeev wrote:
> 03.05.2013 20:52, Greg KH пишет:
> >On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
> >>03.05.2013 20:30, Greg KH пишет:
> >>>We need some way to check the chars in the buffer, is the device you are
> >>>using just very s
03.05.2013 20:52, Greg KH пишет:
On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we c
On Fri, May 03, 2013 at 09:38:50PM +0400, Stas Sergeev wrote:
> 03.05.2013 20:30, Greg KH пишет:
> >We need some way to check the chars in the buffer, is the device you are
> >using just very slow to respond to this request? How slow? Do you have
> >a test case that we can see how it is affected?
03.05.2013 20:30, Greg KH пишет:
We need some way to check the chars in the buffer, is the device you are
using just very slow to respond to this request? How slow? Do you have
a test case that we can see how it is affected?
Greg, unfortunately, I do have nothing.
The customer is in CC list, s
On Fri, May 03, 2013 at 07:02:46PM +0400, Stas Sergeev wrote:
> Hi.
>
> We have a regression because of this patch:
> http://lkml.indiana.edu/hypermail/linux/kernel/1210.1/01456.html
> While it is arguably reasonable to have this for tcdrain or close,
> it also slows down poll/select a lot because
14 matches
Mail list logo