> with the cases where who drives same priority work, are these ide
> drives on the same controller? If it is then we are still back to
> the case where it thrashes if two drives are accessed
> similtaniously
Good point. Of the responses I've had so far, only two have stated
type of controller (both SCSI, one thrashed, the other didn't), and
none have stated channels, so I honestly don't know...
Can everybody who's given a report please provide these details to
help with the analysis?
Best wishes from Riley.
> > From: Riley Williams <rhw@bigfoot.com>
> > Date: Fri, 5 Jun 1998 20:06:53 +0100 (BST)
> > Subject: Swap partition thrashing
> >
> > Hi Michael.
> >
> > >> From the discussion that has taken place recently, the general
> > >> conditions for another bug in the Linux source have been tracked
> > >> down. However, according to the MAINTAINERS file, there is nobody
> > >> responsible for the relevant section of the code.
> >
> > >> From what has been said, there appears to be some sort of
> > >> thrashing occurring in the memory management code that deals with
> > >> swapping to/from disk, which occurs specifically in the following
> > >> circumstances:
> >
> > >> 1. There are TWO OR MORE swap partitions allocated.
> >
> > >> 2. ALL swap partitions have the SAME priority setting.
> >
> > >> I don't know the code well enough at the moment to investigate
> > >> further, but would be interested to discover who's responsible for
> > >> the relevant section of code so I can pass on this report to
> > >> somebody who's better able to handle it than I am...
> >
> > > I think you are on the wrong track here as I have 2 identical 128mb
> > > partitions at the same priority (need interleaved swap) and have
> > > had these in place for quite a long time (2.0.1x).
> >
> > > I have seen thrashing-from-hell, but not with any of the last, say
> > > 10-12 versions or so. I have tried _very_ hard to get the machine
> > > to thrash with no success. What I do see is a whole lot of kswapd
> > > eating most of my io bandwidth for any task which consumes more
> > > than 16 of 80 meg of ram no matter how I tune parameters. I suspect
> > > that this kswapd activity gets toxic only on small memory machines.
> >
> > > This I believe is a known problem which is being addressed by the
> > > vm magicians. It will get better when someone figures out how to
> > > solve the fragmentation issues.. and no sooner I think.
> >
> > Here's a summary of what's been reported so far...
> >
> > 1. Two drives, one partition on each, both pri=1, thrash badly.
> > (Original report).
> >
> > 2. Two drives, one partition on each, pri=-1 and pri=-2, no
> > thrashing. (One of my systems).
> >
> > 3. Three drives, swap on two of them, pri=-1 and pri=-2, no
> > thrashing. (Another of my systems).
> >
> > 4. Three drives, swap on each, two pri=2, one pri=1, thrash badly.
> > (Another report I've received).
> >
> > 5. Three drives, swap on each, two pri=1, one pri=5, no thrashing.
> > (Another report I've received).
> >
> > 6. Two or more swap partitions on same drive, no thrashing with
> > any combination of priorities. (Four reports of this so far).
> >
> > This does suggest a possible set of rules, but more reports are needed
> > to verify them. The rule-set suggested is as follows:
> >
> > 1. TWO OR MORE swap partitions.
> >
> > 2. TWO OR MORE of these SHARE the HIGHEST priority level.
> >
> > 3. The ones that share the highest priority level are on DIFFERENT
> > drives, with not more than one on each drive involved.
> >
> > To ocomplete the picture, I'd like to receive further reports, and
> > ESPECIALLY for either of the following conditions:
> >
> > A. Thrashing NOT occurring when the above conditions are met.
> > Please state your partition setup.
> >
> > B. Thrashing occurring when the above conditions are NOT met.
> > Again, please state your partition setup.
> >
> > However, reports confirming the above premise are also welcome...
> >
> > Best wishes from Riley.
> >
> >
> >
> > ------------------------------
> >
> > End of linux-kernel-digest V1 #2052
> > ***********************************
> >
> > To subscribe to linux-kernel-digest, send the command:
> >
> > subscribe linux-kernel-digest
> >
> > in the body of a message to "Majordomo@vger.rutgers.edu". If you want
> > to subscribe something other than the account the mail is coming from,
> > such as a local redistribution list, then append that address to the
> > "subscribe" command; for example, to subscribe "local-linux-kernel":
> >
> > subscribe linux-kernel-digest local-linux-kernel@your.domain.net
> >
> > A non-digest (direct mail) version of this list is also available; to
> > subscribe to that instead, replace all instances of "linux-kernel-digest"
> > in the commands above with "linux-kernel".
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: PGP for Personal Privacy 5.0
> Charset: noconv
>
> iQEVAwUBNXhHAT7msCGEppcbAQEA2wf9E+VHr+fy2qKS8WC6Y3E7m24iWi/LrAoi
> WAMmDfLIDcLZjpwZPr8Fze5rOn5gb7QkzPh9gd572IfzbQA0tOgbchsxpM2/G2sA
> FBOkvsqmomAatJ54RlWl0S5lRQQjlc8DdlIt0dQfEK/C0oB4d4M4y4CTcd3ad/WZ
> tos4+FuA++fOzvZ+D9CNfLE4QmKLLKMGDDym4ZxQbZd0o8aaUX+UMXj1lHG0AiYs
> BNbSGfjTCXhpVhEmYWqb/C0bCxIEVZXKfsjXBy1qQST1Ohg+BELgM1Hr0s3LDQpY
> wD7kBTqmfOrd0Nb89SoEI3DIm2UqeakzRRg0FtBoJUeWKuvPcpUXWA==
> =nXvF
> -----END PGP SIGNATURE-----
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu