Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*pagebuf\s+page\s+cleaner\s+and\s+page\s+aging\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*pagebuf\s+page\s+cleaner\s+and\s+page\s+aging\s*$/: 24 ]

Total 24 documents matching your query.

1. pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 02:47:07 -0200 (BRST); I've noticed that the page cleaner daemon, which is supposed to map delayed allocations to disk when necessary (out of memory), walks sequentially through whole memory searching for "delayed allocat; /archives/xfs/2001-01/msg00191.html (8,608 bytes)
2. Re: pagebuf page cleaner and page aging (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Fri, 19 Jan 2001 09:10:17 -0600; Yes you are correct in that the page cleaner is insensitive to the age of the data it is working on, it is in effect random. There are a couple of points to be made on the daemon. First, we would re; /archives/xfs/2001-01/msg00195.html (10,854 bytes)
3. Re: pagebuf page cleaner and page aging (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 17:15:17 +0100; I personally think that we _really_ want to get rid of buffer_heads in mm in Linux 2.5. But I think settings the page dirty in prepare/commit_write and letting writepage do all the dirty work is clea; /archives/xfs/2001-01/msg00197.html (10,142 bytes)
4. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 12:38:27 -0200 (BRST); Thats ->writepage(), basically. The problem with write clustering right now is that there is no abstraction defined. The VM must "control" what is flushed, IMO: - the address space owner does not hav; /archives/xfs/2001-01/msg00198.html (11,326 bytes)
5. Re: pagebuf page cleaner and page aging (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Fri, 19 Jan 2001 11:08:47 -0600; There are other aspects of write clustering which are important - at least as far as xfs is concerned. When xfs is asked to flush a delayed allocate page it goes and allocates space for it and all ot; /archives/xfs/2001-01/msg00199.html (13,335 bytes)
6. Re: pagebuf page cleaner and page aging (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxx>; Date: Fri, 19 Jan 2001 18:38:03 +0100; IMHO we should try to give the VM knowlede how to cluster without having to go into the low-level code at all. The idea I had for such information is the notation of a virtual extent. A virtual exten; /archives/xfs/2001-01/msg00201.html (9,636 bytes)
7. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 14:16:31 -0200 (BRST); I would like to have write clustering scheme which can work with advanced features (such as delayed allocation) even if we dont have those features right now in the kernel. Otherwise we'll end up hav; /archives/xfs/2001-01/msg00202.html (12,652 bytes)
8. Re: pagebuf page cleaner and page aging (score: 1): Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>; Date: Fri, 19 Jan 2001 10:20:23 -0800; There's been several mail exchanges already on this thread. Let me try to summarize: 1. The page cleaner should walk the dirty list of pages. 2. There are 2 reasons to start write-out earlier than on; /archives/xfs/2001-01/msg00203.html (9,728 bytes)
9. Re: pagebuf page cleaner and page aging (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxx>; Date: Fri, 19 Jan 2001 19:44:33 +0100; Yepp. (b) should be handled in a generic way (by the mm subsys), but I'm not sure how to do (a). Agreed. Again it should be handled outside XFS, e.g. my generic kiobuf address_space methods start usi; /archives/xfs/2001-01/msg00204.html (10,354 bytes)
10. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 17:24:25 -0200 (BRST); <snip> Ananth, Its obvious there must be a daemon to allocate old unmapped pages and to help write throttling of the delayed allocations. Now I dont see any problem with write clustering (potentially; /archives/xfs/2001-01/msg00205.html (9,288 bytes)
11. Re: pagebuf page cleaner and page aging (score: 1): Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>; Date: Fri, 19 Jan 2001 15:28:45 -0800; You are referring to writepage() doing the conversion & clustering when called from page_launder()? IOW, do the conversion/clustering as part of the memory allocation, right? There are no major issue; /archives/xfs/2001-01/msg00213.html (9,615 bytes)
12. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 20:10:42 -0200 (BRST); Not really . Yes, PF_MEMALLOC can be used. The clustering should be limited (or even removed) if we're under critical memory shortage. These are tuning issues which I'm sure we will have to look more; /archives/xfs/2001-01/msg00214.html (10,093 bytes)
13. pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 02:47:07 -0200 (BRST); I've noticed that the page cleaner daemon, which is supposed to map delayed allocations to disk when necessary (out of memory), walks sequentially through whole memory searching for "delayed allocat; /archives/xfs/2001-01/msg00570.html (8,608 bytes)
14. Re: pagebuf page cleaner and page aging (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Fri, 19 Jan 2001 09:10:17 -0600; Yes you are correct in that the page cleaner is insensitive to the age of the data it is working on, it is in effect random. There are a couple of points to be made on the daemon. First, we would re; /archives/xfs/2001-01/msg00574.html (10,854 bytes)
15. Re: pagebuf page cleaner and page aging (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 17:15:17 +0100; I personally think that we _really_ want to get rid of buffer_heads in mm in Linux 2.5. But I think settings the page dirty in prepare/commit_write and letting writepage do all the dirty work is clea; /archives/xfs/2001-01/msg00576.html (10,142 bytes)
16. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 12:38:27 -0200 (BRST); Thats ->writepage(), basically. The problem with write clustering right now is that there is no abstraction defined. The VM must "control" what is flushed, IMO: - the address space owner does not hav; /archives/xfs/2001-01/msg00577.html (11,326 bytes)
17. Re: pagebuf page cleaner and page aging (score: 1): Author: Steve Lord <lord@xxxxxxx>; Date: Fri, 19 Jan 2001 11:08:47 -0600; There are other aspects of write clustering which are important - at least as far as xfs is concerned. When xfs is asked to flush a delayed allocate page it goes and allocates space for it and all ot; /archives/xfs/2001-01/msg00578.html (13,335 bytes)
18. Re: pagebuf page cleaner and page aging (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxx>; Date: Fri, 19 Jan 2001 18:38:03 +0100; IMHO we should try to give the VM knowlede how to cluster without having to go into the low-level code at all. The idea I had for such information is the notation of a virtual extent. A virtual exten; /archives/xfs/2001-01/msg00580.html (9,636 bytes)
19. Re: pagebuf page cleaner and page aging (score: 1): Author: Marcelo Tosatti <marcelo@xxxxxxxxxxxxxxxx>; Date: Fri, 19 Jan 2001 14:16:31 -0200 (BRST); I would like to have write clustering scheme which can work with advanced features (such as delayed allocation) even if we dont have those features right now in the kernel. Otherwise we'll end up hav; /archives/xfs/2001-01/msg00581.html (12,652 bytes)
20. Re: pagebuf page cleaner and page aging (score: 1): Author: Rajagopal Ananthanarayanan <ananth@xxxxxxx>; Date: Fri, 19 Jan 2001 10:20:23 -0800; There's been several mail exchanges already on this thread. Let me try to summarize: 1. The page cleaner should walk the dirty list of pages. 2. There are 2 reasons to start write-out earlier than on; /archives/xfs/2001-01/msg00582.html (9,728 bytes)

Current List: 1 - 20
Page: [1] [2]