Re: Flush scan list on resume

[Dan Williams <dcbw redhat com>]

On Wed, 2009-02-04 at 19:15 -0500, Tony Espy wrote:
> Dan Williams wrote:
> > On Wed, 2009-02-04 at 15:40 -0800, Howard Chu wrote:
> >> Dan Williams wrote:
> >>> On Wed, 2009-02-04 at 18:04 -0500, Tony Espy wrote:
> >>>> Dan Williams wrote:
> >>>>> So here's why old access points show up after resume...
> >>>>>
> >>>>> Executive summary: exclusively a *driver* problem
> >>>>>
> >>>>>
> >>>>> Detailed explanation:
> >>>>>
> >>>>> Most kernel drivers use 'jiffies' as the timestamp for each scan result.
> >>>>> jiffies is a kernel counter that counts *while the kernel is alive*, and
> >>>>> thus does not reflect time spent in suspend and hibernate.
> >>>>>
> >>>>> When the supplicant requests scan results from the driver on resume, the
> >>>>> supplicant (and NM) gets back a list of scan results with recent-looking
> >>>>> timestamps that do not reflect the time the machine was suspended.
> >>>>>
> >>>>> The solutions are to move drivers to using the actual machine clock (the
> >>>>> kernel equivalent of time(2)) for last_beacon, or to be more agressive
> >>>>> about expiring entries on resume with something like (10 - time spent in
> >>>>> sleep).
> >> OK. Having looked in my wireless-testing tree, I see that most of the drivers 
> >> are now just allowing mac80211 to handle scanning, so this is not a per-driver 
> >> issue. At least that makes the scope of fixing easier to manage.
> >>
> >>>> How 'bout getting drivers to add code to their resume functions that
> >>>> just clears the scan results queue?
> >> I was actually thinking it makes sense to clear results on suspend, no reason 
> >> to keep kmem allocated at that point. (No point in saving an obsolete queue on 
> >> a hibernate, after all.)
> >>
> >>> That's not desirable on mobile platforms like OLPC that do
> >>> suspend/resume very quickly and very often.  The best mechanism is to
> >>> make the *actual* last seen time available to the userspace programs
> >>> that implement the policy (like connection managers) so they can do
> >>> what's appropriate.
> >> OK. I suggest a compromise then, since fetching kernel time will also be 
> >> expensive if done frequently - just fetch it at driver load and resume time, 
> >> and store it as a <base> in the driver. Cache entries then store base+jiffy. 
> >> This allows cache stamps to continue to be cheap, but also solves the 
> >> sleep/resume mismatch.
> > 
> > Yeah, that might work.  Want to whip up a quick patch we can use for
> > further discussion?
> 
> I still think simple ( ie. either have mac80211 handle the expiration or 
> flush of scan results on resume ) wins out over the more complicated 
> approach of having the connection manager handle expiration of older 
> scan results.
> 
> Also a mobile device ( eg. a netbook or OLPC ) could be moving relative 
> to the same set of access points while in S3 ( ie. within a single 
> office and/or building ), and that the cached scan results after resume 
> could reflect inaccurate relative signal strengths of the the APs.  This 
> could effect roaming performance.

To be fair, OLPC's use-case was suspend/resume whenever the machine was
idle, and that could be between keystrokes (which was actually the
target case).  Thus, clearing the list every keystroke wouldn't be that
great.

In any case, that's a theoretical use-case since they never got there.
It's better to, as you suggest, clear the list on suspend and if that's
not suitable at some point in the future, change it.

Upstream, Johannes likes the (10 - time in suspend) better (since he
suggested that anyway), so a patch that does that would be more awesome
than one that just clears the scan list unconditionally.

Dan