Messages in this thread | | | Date | Fri, 5 Jun 1998 22:07:41 +0100 (BST) | From | Riley Williams <> | Subject | Re: linux-kernel-digest V1 #2052 |
| |
Hi David.
> 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
| |