[linuxsh-shmedia-dev] Re: Swap Issues (was [linuxsh-shmedia-bk] bk commit ... )

[Paul M. <le...@li...>]

Hi Richard,

On Fri, Jun 27, 2003 at 12:02:49PM +0100, Richard Curnow wrote:
> [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]
>=20
There's also other related threads in the linuxsh-shmedia-bk archives, for
anyone that's interested.

> Well quite :-)  Unfortunately, it's the only option I have at the
> moment, as due to lack of working IDE, SCSI or USB2.
>=20
That's not entirely true, if you swith the fb off you can still somewhat
reliably use the kyro for swap. If you're getting nailed by PCI ARB interru=
pts
though, doing so might just increase the frequency of which you get these
triggered.

> 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 :
>=20
There's also driver-specific hacks, including the sh-sci changes.

> * 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).
>=20
It would be good to get this in sooner then later, particularly with 2.4.22
looming not far off.

> * The change you've just made to mm/memory.c
>=20
The obvious workaround for this is to simply go back to wrapping the
flush_page_to_ram() to flush_dcache_page() in arch/sh64/mm/cache.c

This then also raises the issue if we want to back out the _other_ performa=
nce
hacks, ie, flush_cache_page(), flush_icache_page(), and so forth.

I think in the general case that's not really that interesting, so it's
probably more sensible to just fixup flush_page_to_ram() in stock 2.4,
and keep performance hacks like this in the BK tree.

> 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.
>=20
If you only do relatively light swapping, or pull back on some of the load
once the swap bar gets higher, does it still work without triggering the
interrupt?

> 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?
>=20
Not directly, that's more of a sanity thing. For things using the PCI DMA
API, there's otherwise the chance of them getting handed stale memory.

> 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.
>=20
Indeed. Getting things synced up would be nice.