From: "Chris Friesen" <cfriesen@nortel.com>
To: Todd Tomaino <ttomaino@rivulet.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: E1000: e1000_update_stats()
Date: Wed, 05 Mar 2008 15:22:39 -0600 [thread overview]
Message-ID: <47CF0F1F.1080402@nortel.com> (raw)
In-Reply-To: <67F3071335CB9945A6047FE06957E0240D6D94CE93@exchange.rivulet.com>
Todd Tomaino wrote:
> Reading the comments in the code it appeared that updating
> adapter->net_stats and adapter->stat required interrupts to be turned
> off to prevent the e1000_adjust_tbi_stats() function from modifying
> these structures from interrupt context. In order to reduce the
> amount of time spent with interrupts disabled I separated the
> register reads from updating adapter->stat counters. The register
> reads take up the bulk of the 57 usec and shouldn't require
> protection (I could be wrong). The new operation looks like this and
> reduces the amount of time spent with interrupts turned off by 1/2:
>
> 1. read registers 2. acquire spinlock 3. update adapter->stat
> counters 4. update OS adapter->net_stats statistics 5. update phy
> stats. 6. release spinlock.
One potential problem with this is that the stats can be further out of
date.
Consider this case:
cpu0 reads some of the registers, then gets preempted/interrupted
cpu1 reads all the registers, updates the stats, then dumps the data
At this point cpu1 dumped information that doesn't include the registers
that cpu0 was in the middle of updating. Eventually cpu0 will run again
and the stats will be accurate, but there is a window where the stats
may be self-inconsistent and the various counts may not add up.
Chris
next prev parent reply other threads:[~2008-03-05 21:23 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-03-05 20:45 E1000: e1000_update_stats() Todd Tomaino
2008-03-05 21:22 ` Chris Friesen [this message]
2008-03-05 21:40 ` Kok, Auke
2008-03-05 22:00 ` Chris Friesen
2008-03-05 21:34 ` Kok, Auke
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=47CF0F1F.1080402@nortel.com \
--to=cfriesen@nortel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=ttomaino@rivulet.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