Hi,
I think there are some problems in the current (pre7-1) shrink_mmap.
1) "Random" resorting for zone with free_pages > pages_high
while loop searches from the end of the list.
old pages on non memory pressure zones are disposed as 'young'.
Young pages are put in front, like recently touched ones.
This results in a random resort for these pages.
2) The implemented algorithm results in a lot of list operations -
each scanned page is deleted from the list.
3) The list is supposed to be small - it is not...
(se attachment, ALT-SysRQ-m)
12000 elements on a 96 MB computer after doing a find
4) Count is only decreased for suitable pages, but is related
to total pages.
5) Returns on first fully successful page. Rescan from beginning
at next call to get another one... (not that bad since pages
are moved to the end)
Suggestion:
Scan for suitable page, referenced to &young.
Split at suitable; add older part to &old, unlink suitable.
Process suitable.
Put as oldest in &old (list_add_tail) if it could not be freed
right now. (note results in resorting too...)
Count and return stuff is worse, is it acceptable to not starting
dec of count until first acceptable is found, and then dec for
all checked?
/RogerL
Rik van Riel wrote:
>
> On 1 May 2000, Oystein Viggen wrote:
> > Oystein Viggen wrote:
> > > Matthew Dharm wrote:
> > >
> > > > I can confirm similar behavior on my system as well. I'm running
> > > > 2.3.99-pre7. I was doing a diff of two kernel trees and kswapd started
> > > > eating CPU like no tomorrow.
> > >
> > > Actually, I can reproduce the exact same problem by just dd'ing a lot from
> > > /dev/zero to some other file on a UDMA/33 disk on my K6-2 350 with an Asus
> > > p5a motherboard (ali aladdin chipset). This is on 2.3.99-pre6. I did not
> > > notice this on pre5
>
> > When the dd was almost half done, the whole computer froze until
> > the process was almost done. In this time user input was
> > impossible and some net connections died, probably from timeout.
> >
> > As a sidenode, non-I/O bound processes (ie quakeworld) seem to
> > run just fine with no noticeable speed loss.
>
> What people may want to try is using the old order of aging
> and chosing which pages to evict in shrink_mmap(). It is
> slightly broken and gives worse performance for "normal"
> workload, but maybe it gives better performance for heavy
> IO bound workloads.
>
> OTOH, maybe it doesn't help at all and the combination of
> zoned allocation and global page replacement is too cpu
> hungry. Then again, not doing global page replacement just
> isn't good either....
>
> (except maybe an "emergency" reclaim-from-one-zone-only mode
> combined with a weighed round-robin reclaim from all zones
> until one of them reaches zone->pages_high???)
>
> Rik
> --
> The Internet is not a network of computers. It is a network
> of people. That is its real strength.
>
> Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
> http://www.conectiva.com/ http://www.surriel.com/
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-- Home page: http://www.norran.net/nra02596/
May 2 00:02:43 dox kernel: SysRq: Show Memory May 2 00:02:43 dox kernel: Mem-info: May 2 00:02:43 dox kernel: Free pages: 2200kB ( 0kB HighMem) May 2 00:02:43 dox kernel: ( Free: 550, lru_cache: 12290 (192 384 576) ) May 2 00:02:43 dox kernel: DMA: 32*4kB 1*8kB 0*16kB 0*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB = 392kB) May 2 00:02:43 dox kernel: Normal: 22*4kB 25*8kB 11*16kB 4*32kB 1*64kB 1*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB = 1808kB) May 2 00:02:43 dox kernel: HighMem: = 0kB) May 2 00:02:43 dox kernel: Swap cache: add 65, delete 53, find 0/0 May 2 00:02:43 dox kernel: Free swap: 132788kB May 2 00:02:43 dox kernel: 24576 pages of RAM May 2 00:02:43 dox kernel: 0 pages of HIGHMEM May 2 00:02:43 dox kernel: 1371 reserved pages May 2 00:02:43 dox kernel: 12029 pages shared May 2 00:02:43 dox kernel: 12 pages swap cached May 2 00:02:43 dox kernel: 0 pages in page table cache May 2 00:02:43 dox kernel: Buffer memory: 12652kB May 2 00:03:19 dox kernel: SysRq: Show Memory May 2 00:03:19 dox kernel: Mem-info: May 2 00:03:19 dox kernel: Free pages: 4324kB ( 0kB HighMem) May 2 00:03:19 dox kernel: ( Free: 1081, lru_cache: 12079 (192 384 576) ) May 2 00:03:19 dox kernel: DMA: 54*4kB 19*8kB 17*16kB 1*32kB 0*64kB 0*128kB 1*256kB 0*512kB 0*1024kB 0*2048kB = 928kB) May 2 00:03:19 dox kernel: Normal: 129*4kB 60*8kB 26*16kB 14*32kB 4*64kB 2*128kB 0*256kB 0*512kB 1*1024kB 0*2048kB = 3396kB) May 2 00:03:19 dox kernel: HighMem: = 0kB) May 2 00:03:19 dox kernel: Swap cache: add 70, delete 64, find 1/1 May 2 00:03:19 dox kernel: Free swap: 132812kB May 2 00:03:19 dox kernel: 24576 pages of RAM May 2 00:03:19 dox kernel: 0 pages of HIGHMEM May 2 00:03:19 dox kernel: 1371 reserved pages May 2 00:03:19 dox kernel: 10453 pages shared May 2 00:03:19 dox kernel: 6 pages swap cached May 2 00:03:19 dox kernel: 0 pages in page table cache May 2 00:03:19 dox kernel: Buffer memory: 13188kB May 2 00:17:37 dox -- MARK --
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun May 07 2000 - 21:00:09 EST