mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Open Source <opensource3141@yahoo.com>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: linux-usb-devel@lists.sourceforge.net, linux-kernel@vger.kernel.org
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)
Date: Wed, 18 Oct 2006 16:35:07 -0700 (PDT)	[thread overview]
Message-ID: <20061018233507.16615.qmail@web58114.mail.re3.yahoo.com> (raw)

Hi Alan and all,

I have run the "strace -r -f" as you had recommended
and the problem revealed itself.  I did some cross-checking
and I'm pretty sure I have found the issue.

Basically, I was barking up the wrong tree in assuming
this was a USB subsystem issue.  As people correctly
pointed out, the change to CONFIG_HZ has affected
many things.  In my case, I was using a library that issued
a nanosleep for a particular amount of time. Most often
the sleep time is 0, but the library was still calling
nanosleep({0, 0}).  This seemed to put the running process
to sleep (for 0 time) but it only was woken up at the next
timer interrupt (1 ms period for pre-2.6.13 and 4 ms for
2.6.13 and up).

I do not know if this is the desired behavior of nanosleep.
 For example, In Windows, calling Sleep with a zero time,
and no other processes hogging the CPU, does not seem
illicit the same effect as in Linux.  There, no time is
expended.  However, I can understand that there could
be technical reasons to leave nanosleep's behavior like this.

In any case, I apologize for causing ruckus and shifting
the blame incorrectly to USB.  Thank you all for your
advice.  I wouldn't have been able to narrow it down so
easily without it, especially the use of "strace -r" which is
something very useful that I did not know despite
developing on Linux for over a decade!

Furthermore, I am very glad to know that this is not one
of those user-mode-issues-that-can-only-be-solved-by-going-
to-kernel-mode. At least my intuition was correct there.  Things
should be snappy if no other processes are running on the system,
even if the application is in user mode!

Also, here are a few articles that might be useful to other
scheduler newbies like myself:

] http://josh.trancesoftware.com/linux/linux_cpu_scheduler.pdf
] http://kerneltrap.org/node/5411

Thanks again.
Satisfied Open Source Fan


----- Original Message ----
From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: Open Source <opensource3141@yahoo.com>
Cc: Alan Stern <stern@rowland.harvard.edu>; linux-usb-devel@lists.sourceforge.net; WolfgangMües <wolfgang@iksw-muees.de>; linux-kernel@vger.kernel.org
Sent: Friday, October 13, 2006 4:41:44 PM
Subject: Re: [linux-usb-devel] USB performance bug since kernel 2.6.13 (CRITICAL???)

Ar Gwe, 2006-10-13 am 16:02 -0700, ysgrifennodd Open Source:
> clear understanding of what is causing it.  As it stands it doesn't
> seem like even the experts know exactly where this
> delay is being caused.

strace should tell you precisely how long each syscall takes if you ask
it to trace things nicely. If you have code trying to wait for a tiny
time then HZ will bump the wait to be longer (kernel or user) but for
other cases all should be fine either way.

The other issues like priority and paging caused delays can generally be
dealt with by having the relevant service code running mlockall and real
time priority.








             reply	other threads:[~2006-10-18 23:35 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-18 23:35 Open Source [this message]
  -- strict thread matches above, loose matches on Subject: below --
2006-10-14  0:24 Alan Cox
2006-10-14  2:11 ` [linux-usb-devel] " Alan Stern
2006-10-13 23:02 Open Source
2006-10-13 23:41 ` Alan Cox
2006-10-13 19:31 Open Source
2006-10-13 21:08 ` [linux-usb-devel] " Alan Stern
2006-10-13 23:33 ` David Brownell
2006-10-13 17:20 Open Source
2006-10-13 18:02 ` Alan Stern
2006-10-13 20:24 ` Bob Copeland
2006-10-12 19:33 Open Source
2006-10-13 13:56 ` [linux-usb-devel] " Alan Stern

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=20061018233507.16615.qmail@web58114.mail.re3.yahoo.com \
    --to=opensource3141@yahoo.com \
    --cc=alan@lxorguk.ukuu.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    /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®