public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Casey Leedom <leedom@chelsio.com>
To: "Luis R. Rodriguez" <mcgrof@suse.com>
Cc: "Luis R. Rodriguez" <mcgrof@do-not-panic.com>,
	hariprasad@chelsio.com, poswald@suse.com, santosh@chelsio.com,
	jcheung@suse.com, dchang@suse.com, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [RFT 0/3] cxgb4: use request_firmware_nowait()
Date: Tue, 24 Jun 2014 09:34:19 -0700	[thread overview]
Message-ID: <53A9A88B.2000006@chelsio.com> (raw)
In-Reply-To: <53A99F71.2060308@chelsio.com>


On 06/24/14 08:55, Casey Leedom wrote:
>
> On 06/23/14 17:29, Luis R. Rodriguez wrote:
>> On Mon, Jun 23, 2014 at 12:06:48PM -0700, Casey Leedom wrote:
>>
>>> Also, it might be useful if there was a way for the driver
>>> module to "tell" the timeout mechanism that forward progress _is_ being
>>> made so it doesn't blow away the driver module load.
>> Indeed if this is actually needed, but believe the issue here for the
>> huge delays might be instead the lack of not using 
>> request_firmware_direct()
>> and actual device initialization time, which I do not believe we 
>> penalize,
>> we should be penalizing only the amount of time it takes either the
>> kernel or udev to read the firmware from the filesystem.
>
>   If you want I can time the actual phases of loading new firmware: 
> request_firmware(), writing it to FLASH, release_firmware() ...

   So I just did this for a normal modprobe (after the system is up):

Jiffies    Process
-----------------------------------------------------------------------
       0    begin firmware load process
       3    request_firmware() returns
       7    start looking at the adapter
      10    finish reading the first sector of existing adapter firmware
      26    we've decided that we're going to upgrade the firmware
      28    actual firmware upgrade process starts
     448    we've finished halting the adapter processor
     451    we enter the firmware write routine
   8,470    we've finished erasing the firmware FLASH sectors
  14,336    write of new firmware is complete
  14,340    the new firmware load is complete
  14,949    the adapter processor has been restarted; new firmware running
  14,952    firmware upgrade process complete

Maybe request_firmware() takes more time during the boot phase but as we 
can see from the above timings, it's the actual firmware upgrade process 
which takes the most time ...

Casey

  reply	other threads:[~2014-06-24 16:34 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-21  0:39 [RFT 0/3] cxgb4: use request_firmware_nowait() Luis R. Rodriguez
2014-06-21  0:39 ` [RFT 1/3] cxgb4: make ethtool set_flash " Luis R. Rodriguez
2014-06-21  0:39 ` [RFT 2/3] cxgb4: make configuration load " Luis R. Rodriguez
2014-06-21  0:39 ` [RFT 3/3] cxgb4: make device firmware " Luis R. Rodriguez
2014-06-23 19:06 ` [RFT 0/3] cxgb4: " Casey Leedom
2014-06-24  0:29   ` Luis R. Rodriguez
2014-06-24 15:55     ` Casey Leedom
2014-06-24 16:34       ` Casey Leedom [this message]
2014-06-24 23:39         ` Luis R. Rodriguez
2014-06-25  2:00           ` Luis R. Rodriguez
2014-06-25 21:51             ` Luis R. Rodriguez
2014-06-26  0:08               ` Luis R. Rodriguez

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=53A9A88B.2000006@chelsio.com \
    --to=leedom@chelsio.com \
    --cc=dchang@suse.com \
    --cc=hariprasad@chelsio.com \
    --cc=jcheung@suse.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=mcgrof@suse.com \
    --cc=netdev@vger.kernel.org \
    --cc=poswald@suse.com \
    --cc=santosh@chelsio.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