[linuxsh-shmedia-dev] Re: [linuxsh-shmedia-bk] bk commit: lethal@lemmiwinks.internal.linux-sh.org:/home/lethal/devel/bk/shmedia-2.4

[Richard C. <Ric...@su...>]

[for those on linux-shmedia-dev : this started off as a private thread
between Paul and me about work we're doing to fix swapping, but it's
probably of general interest too now - if anyone wants to pick up the
rest of the thread give us a shout]

Hi Paul

* Paul Mundt <le...@li...> [2003-06-26]:
> Indeed. Lack of anything resembling what could potentially be concieved as
> performance would be a sheer indicator that USB1.1 isn't much of a viable swap
> option.

Well quite :-)  Unfortunately, it's the only option I have at the
moment, as due to lack of working IDE, SCSI or USB2.

> > I still think we should continue the push to check each caller to
> > flush_page_to_ram and find which one is the culprit.  If we can engineer
> > just that one to use the flush_dcache_page mechanism instead, we should
> > see a performance boost.
> > 
> Agreed. Though this leaves us with a few potential problems. Namely, we'll
> likely have to have flush_page_to_ram() wrapping to flush_dcache_page() in 
> stock 2.4 (once Marcelo takes it), as we likely won't be able to get those
> flushes wrapped in stock 2.4 (this will have to be something that we keep
> isolated to the linux-shmedia tree, obviously).

On a general note, maybe soon we should diff the generic parts of our
tree against a vanilla Marcelo tree, and find where we've made changes
in generic to fix things.  Before we can merge sh64 into the mainline,
we either need to workaround these in arch, or get Marcelo to accept the
changes.  Personally I know of 3 now :

* a usb-ehci compile fix (missing include) - I've already got this in
  through Greg-KH (went in right after 2.4.21)

* a problem in fs/nfs/nfs3proc.c (nfs3_proc_unlink_setup) where two
  allocations are done with one kmalloc and the 2nd ends up with
  insufficient alignment.  This was discussed on lkml with Trond and
  seemed to be acceptable, although I botched the patch twice and need
  to clean it up and resubmit it formally.  It's not been fixed
  externally yet (according to bk revtool).

* The change you've just made to mm/memory.c

> If it's generally harmless, it may be useful to just remove the printk()
> altogether. I can't imagine a customer being pleased with being flooded
> by invalid pte warnings. (At my last job, rather, when I still had one, we had
> to hack all of the module tainting stuff out since customers kept getting
> scared by it) -- I can't imagine invalid pte warnings being recieved any
> better.

I've removed it in my tree and committed it.

> 
> > My runs are always getting killed by PCI ARB interrupts, after which the
> > external disc access light is stuck on and everything in D-state is
> > deadlocked.  This happens with both the external Maxtor 120G HDD (USB2)
> > and the ZIP (USB1.1), though it seems like swapping to the ZIP lasts for
> > longer.
> > 
> Odd. It might be useful to hook up a PCI bus analyzer and see what it has to
> say about it.

I've just had a run going with a load av of >12, typically 30-40Mb into
swap, which lasted 30 minutes, before it died with another of these.
Maybe there's a corner case with this USB1 card.  But I'm quite pleased
with this because it looks like the swapping is generally reliable now.

I had a gkrellm running at the time of the crash, and the swap bar has
frozen right at the top.  So I wonder if there's a problem with the USB
path to the disc when it's driven into very high load.

I saw you committed a change the other day to do with cache coherency
for PCI DMAs - is that related to any of this stuff?

> You may wish to do a pull as well if you haven't recently, since you may
> end up getting fairly out of sync otherwise.

I've been syncing my tree every day (although our internal site tree
that the others use is now 100's of changesets out of date.)  I need to
push my changes back out sometime, though.

-- 
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
  P.    /// ric...@su...  ///  rc...@rc...
Curnow  \\\ http://www.superh.com/    ///  www.rc0.org.uk