All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergei Organov <osv@javad.com>
To: Alan Cox <alan@redhat.com>
Cc: linux-serial@vger.kernel.org
Subject: Re: [Q] New tty flip interface doubt.
Date: Thu, 22 Jun 2006 19:17:50 +0400	[thread overview]
Message-ID: <87d5d15ie9.fsf@javad.com> (raw)
In-Reply-To: <20060622125652.GA23090@devserv.devel.redhat.com> (Alan Cox's message of "Thu, 22 Jun 2006 08:56:52 -0400")

Alan Cox <alan@redhat.com> writes:
> On Thu, Jun 22, 2006 at 11:33:15AM +0400, Sergei Organov wrote:
>> One more question, if I get memory for N bytes with
>> tty_prepare_flip_string() then store M (M <= N) bytes into the buffer,
>> how do I tell tty layer that only M bytes are in fact stored?
>
> You don't.
>
>> [I'm thinking about eliminating buffers allocation for urbs as well as
>> data copy when transferring data from USB subsystem to flip buffers of
>> the tty subsystem. Currently the flow is:
>
> The tty buffers may not be DMAable

I saw this warning, but didn't think that USB urbs must be given DMAable
memory. Does "transfer_buffer: This buffer has to be allocated as a
non-pageable contiguous physical memory block" imply the memory must be
DMAable? If it doesn't, then do tty buffers meet the above cited
requirement?

>
>> and it seems that using tty buffers directly is a better idea:
>> 
>> - allocate N-bytes data buffer from tty and use it for urb
>> - submit the urb to USB subsystem
>> - flip M-bytes of data (M <= N) in USB receive callback.
>
> Its doable in theory but is it worth it ?

Well, I don't actually know, -- does your experience suggest it is not? 

I thought that saving roughly 30% memory (ttys require x2 memory due to
flags, right?) plus eliminating memcpy(), could be a valuable
improvement, especially for embedded/low end systems and/or USB2 speeds.

If you don't see some hard to avoid obstacles making it difficult to
implement, I'll probably try to modify tty layer to be able to support
such a feature to see what it gives.

[My daily job is programming real-time applications for embedded
systems, and time to time I do consider Linux a platform for our future
embedded development.  Recent progress of the kernel towards
preemptibility and real-time performance is very promising, so I'm
somewhat interested party indeed.]

-- 
Sergei.

  reply	other threads:[~2006-06-22 15:18 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-06-21 12:16 [Q] New tty flip interface doubt Sergei Organov
2006-06-21 13:42 ` Alan Cox
2006-06-22  7:33   ` Sergei Organov
2006-06-22 12:56     ` Alan Cox
2006-06-22 15:17       ` Sergei Organov [this message]
2006-06-23 13:16         ` Alan Cox

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=87d5d15ie9.fsf@javad.com \
    --to=osv@javad.com \
    --cc=alan@redhat.com \
    --cc=linux-serial@vger.kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.