All of lore.kernel.org
 help / color / mirror / Atom feed
From: Denis Joseph Barrow <D.Barow@option.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Bird <ajb@spheresystems.co.uk>,
	Linux USB kernel mailing list <linux-usb@vger.kernel.org>,
	Linux netdev Mailing list <netdev@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@suse.de>
Subject: Re: A few design questions wrt the hso driver.
Date: Wed, 01 Oct 2008 16:10:22 +0200	[thread overview]
Message-ID: <48E384CE.8040200@option.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0810011006430.2421-100000@iolanthe.rowland.org>

Hi Alan,
Thank you good sir, I'll look into it.

Alan Stern wrote:
> On Wed, 1 Oct 2008, Denis Joseph Barrow wrote:
> 
>> Now a more involved question.
>> The suspend resume code in hso.c hso_get_activity &
>> hso_put_activity code to me looks very racy but the code seems to be working relatively reliably
>> because the schedule resume stuff happens at a slow pace. 
>> Despite the codes simplicity I do not have a good feel for whether it
>> is stable or not & don't feel like an authority on how to make the code better.
>>
>> The more obvious possible issues I see with it the code are,
>> I could be wrong if I am please say so.
>> 1) On smp systems there is a
>> workqueue for each cpu which means
>> that if one cpu workqueue is not going to be scheduled soon & the other 
>> workqueue is, if a suspend is queued on the cpu which is busy
>> & a resume is later queued on the cpu with soon to run workqueue
>> the resume will most likely happen before the suspend i.e. out of order.
>>
>> 2) Also only the schedule_work will only queue the
>> request once so if multiple schedule works happen
>> only the first one is accepted even if you wanted
>> to change the order of the suspend resume requests later on
>> they won't reorder.
> 
> I agree that the code looks very racy.  You may be able to improve it
> by using the new infrastructure in this patch:
> 
> 	http://marc.info/?l=linux-usb&m=122279021325200&w=2
> 
> It is intended specifically for handling asynchronous suspends and 
> resumes.
> 
> Alan Stern


-- 
best regards,
D.J. Barrow

  reply	other threads:[~2008-10-01 14:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-01 12:16 A few design questions wrt the hso driver Denis Joseph Barrow
     [not found] ` <48E36A0A.9080003-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
2008-10-01 12:27   ` Andrew Bird (Sphere Systems)
2008-10-01 14:09   ` Alan Stern
2008-10-01 14:10     ` Denis Joseph Barrow [this message]
2008-10-01 12:57 ` Paulius Zaleckas

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=48E384CE.8040200@option.com \
    --to=d.barow@option.com \
    --cc=ajb@spheresystems.co.uk \
    --cc=gregkh@suse.de \
    --cc=linux-usb@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=stern@rowland.harvard.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 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.