mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Christopher Li <usb-devel@chrisli.org>
To: Pete Zaitcev <zaitcev@redhat.com>
Cc: Christopher Li <chrisl@vmware.com>,
	linux-usb-devel@lists.sourceforge.net,
	linux-kernel@vger.kernel.org
Subject: Re: PATCH] incrase usbdevfs bulk buffer size
Date: Sun, 2 Oct 2005 15:34:22 -0400	[thread overview]
Message-ID: <20051002193422.GH3453@64m.dyndns.org> (raw)
In-Reply-To: <20051002150829.35107f91.zaitcev@redhat.com>

On Sun, Oct 02, 2005 at 03:08:29PM -0700, Pete Zaitcev wrote:
> On Sat, 1 Oct 2005 16:20:59 -0400, Christopher Li <chrisl@vmware.com> wrote:
> 
> > I hit this limit with running ehci in the VM. The a single ehci
> > qTD transfer buffer can be 5 pages long, that is 20K. [...]
> 
> Even 16K is too much, IMHO.
> 
> > I can complicate the user space part to work around that,
> > but it seems much simpler just allow usbdevfs to accept bigger buffers.
> 
> It seems, yes. However, I assure you that this is not going to
> work for anyone who has anything reasonable swapped out, because
> of the kmalloc().
> 
> 16K is an order 2 allocation on systems with 4KB pages, such as
> Opteron. It kinda sorta works, but not really.
> 
> This looks like a requirement to think about a better API. Also,

I think the API is kind of fine in this aspect. The usbdevfs should be
able to take bigger than 16K, but the internal copy of the urb does not
have to use kmalloc on data buffers.

> the things that Harald was trying to fix, with pids and signals,
> just tell me that something was really wrong from the start.

More detail please?

Chris

  reply	other threads:[~2005-10-02 23:05 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-10-01 20:20 [PATCH] " Christopher Li
2005-10-02 22:08 ` PATCH] " Pete Zaitcev
2005-10-02 19:34   ` Christopher Li [this message]
2005-10-03  4:10     ` Pete Zaitcev
2005-10-03  3:05       ` Christopher Li

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=20051002193422.GH3453@64m.dyndns.org \
    --to=usb-devel@chrisli.org \
    --cc=chrisl@vmware.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=zaitcev@redhat.com \
    /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

Powered by JetHome