mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "George Spelvin" <linux@horizon.com>
Cc: tytso@mit.edu, linux@horizon.com, linux-kernel@vger.kernel.org
Subject: Re: [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll order.
Date: Sun, 16 Nov 2008 15:51:03 +0000	[thread overview]
Message-ID: <20081116155103.22e09a9a@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <20081116152352.20261.qmail@science.horizon.com>

> In desktop hardware, yes.  But PC-104 equipment (for the benefit of
> confused bystandaers, that's classic ISA bus in a different form factor)
> is still going strong; I just added an 8-port serial card to a little

Oh dear. I thought the compact PCI people had exterminated that dinosaur.

> But even PCI reads are slow, and the current code does not optimize the
> case when interrupts are level-sensitive.  (The optimization is trivial,
> but detecting whether the interrupt is edge- or level-sensitive looks
> messy.)

I think you would need to remember that when the port was configured
initially, but yes that would be a much more useful change for most users.

> The real over-optimization argument that I can think of is that emptying 8 bytes
> out of a FIFO involves 16 register reads (LSR + receive data for each byte),
> compared to which the time to poll a few IIRs is not too much.  (Of course, then
> there's low_latency mode.)

So perhaps the right way to approach this is to use two IRQ handlers, one
for level triggered interrupts which doesn't keep polling, and one for
edge triggered which expects the single device case but can re-order your
device scans as you propose.

That would make PCI handling faster, keep normal ISA handling the same
(and with no extra complexity for a list of length one device) and speed
up the case you care about ?

Does that seem practical ?

Alan

  reply	other threads:[~2008-11-16 15:51 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20081113150308.3590.qmail@science.horizon.com>
     [not found] ` <20081114053042.11532.qmail@science.horizon.com>
2008-11-14 21:17   ` [RFC 1/2] serial/8250.c: Change to singly linked handler chain George Spelvin
     [not found]   ` <20081114053314.12093.qmail@science.horizon.com>
2008-11-14 21:34     ` [RFC 2/2] serial/8250.c: Use self-adjusting list for port poll order George Spelvin
2008-11-14 21:47       ` Alan Cox
2008-11-15  0:10         ` Theodore Tso
2008-11-16 15:23           ` George Spelvin
2008-11-16 15:51             ` Alan Cox [this message]
2008-11-16 16:57               ` George Spelvin
2008-11-16 16:23             ` Theodore Tso
2008-11-16 18:02               ` George Spelvin
2008-11-16 16:49             ` Theodore Tso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20081116155103.22e09a9a@lxorguk.ukuu.org.uk \
    --to=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=tytso@mit.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®