vmscan: Do not writeback pages in direct reclaim
in [Kernel]
|
Prev: [tip:x86/mce] x86, mce: Fix MSR_IA32_MCI_CTL2 CMCI threshold setup
Next: [PATCH] drivers/net/e1000/e1000_main.c: Fix message logging defect
From: Mel Gorman on 6 Jul 2010 06:20 On Tue, Jul 06, 2010 at 09:36:41AM +0900, KOSAKI Motohiro wrote: > Hello, > > > Ok, that's reasonable as I'm still working on that patch. For example, the > > patch disabled anonymous page writeback which is unnecessary as the stack > > usage for anon writeback is less than file writeback. > > How do we examine swap-on-file? > Anything in particular wrong with the following? /* * For now, only kswapd can writeback filesystem pages as otherwise * there is a stack overflow risk */ static inline bool reclaim_can_writeback(struct scan_control *sc, struct page *page) { return !page_is_file_cache(page) || current_is_kswapd(); } Even if it is a swapfile, I didn't spot a case where the filesystems writepage would be called. Did I miss something? -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: KOSAKI Motohiro on 6 Jul 2010 07:20 > On Tue, Jul 06, 2010 at 09:36:41AM +0900, KOSAKI Motohiro wrote: > > Hello, > > > > > Ok, that's reasonable as I'm still working on that patch. For example, the > > > patch disabled anonymous page writeback which is unnecessary as the stack > > > usage for anon writeback is less than file writeback. > > > > How do we examine swap-on-file? > > > > Anything in particular wrong with the following? > > /* > * For now, only kswapd can writeback filesystem pages as otherwise > * there is a stack overflow risk > */ > static inline bool reclaim_can_writeback(struct scan_control *sc, > struct page *page) > { > return !page_is_file_cache(page) || current_is_kswapd(); > } > > Even if it is a swapfile, I didn't spot a case where the filesystems > writepage would be called. Did I miss something? Hmm... Now, I doubt I don't understand your mention. Do you mean you intend to swtich task stack when every writepage? It seems a bit costly. but otherwise write-page for anon makes filesystem IO and stack-overflow. Can you please elaborate your plan? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Minchan Kim on 6 Jul 2010 07:30 Hi, Mel. On Tue, Jul 6, 2010 at 7:12 PM, Mel Gorman <mel(a)csn.ul.ie> wrote: > On Tue, Jul 06, 2010 at 09:36:41AM +0900, KOSAKI Motohiro wrote: >> Hello, >> >> > Ok, that's reasonable as I'm still working on that patch. For example, the >> > patch disabled anonymous page writeback which is unnecessary as the stack >> > usage for anon writeback is less than file writeback. >> >> How do we examine swap-on-file? >> > > Anything in particular wrong with the following? > > /* > * For now, only kswapd can writeback filesystem pages as otherwise > * there is a stack overflow risk > */ > static inline bool reclaim_can_writeback(struct scan_control *sc, > struct page *page) > { > return !page_is_file_cache(page) || current_is_kswapd(); > } > > Even if it is a swapfile, I didn't spot a case where the filesystems > writepage would be called. Did I miss something? As I understand Kosaki's opinion, He said that if we make swapout in pageout, it isn't a problem in case of swap device since swapout of block device is light but it is still problem in case of swap file. That's because swapout on swapfile cause file system writepage which makes kernel stack overflow. Do I misunderstand kosaki's point? -- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Mel Gorman on 6 Jul 2010 11:30 On Tue, Jul 06, 2010 at 08:24:57PM +0900, Minchan Kim wrote: > Hi, Mel. > > On Tue, Jul 6, 2010 at 7:12 PM, Mel Gorman <mel(a)csn.ul.ie> wrote: > > On Tue, Jul 06, 2010 at 09:36:41AM +0900, KOSAKI Motohiro wrote: > >> Hello, > >> > >> > Ok, that's reasonable as I'm still working on that patch. For example, the > >> > patch disabled anonymous page writeback which is unnecessary as the stack > >> > usage for anon writeback is less than file writeback. > >> > >> How do we examine swap-on-file? > >> > > > > Anything in particular wrong with the following? > > > > /* > > �* For now, only kswapd can writeback filesystem pages as otherwise > > �* there is a stack overflow risk > > �*/ > > static inline bool reclaim_can_writeback(struct scan_control *sc, > > � � � � � � � � � � � � � � � � � � � �struct page *page) > > { > > � � � �return !page_is_file_cache(page) || current_is_kswapd(); > > } > > > > Even if it is a swapfile, I didn't spot a case where the filesystems > > writepage would be called. Did I miss something? > > > As I understand Kosaki's opinion, He said that if we make swapout in > pageout, it isn't a problem in case of swap device since swapout of > block device is light Sure > but it is still problem in case of swap file. > That's because swapout on swapfile cause file system writepage which > makes kernel stack overflow. > I don't *think* this is a problem unless I missed where writing out to swap enters teh filesystem code. I'll double check. -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Johannes Weiner on 6 Jul 2010 16:30
On Tue, Jul 06, 2010 at 04:25:39PM +0100, Mel Gorman wrote: > On Tue, Jul 06, 2010 at 08:24:57PM +0900, Minchan Kim wrote: > > but it is still problem in case of swap file. > > That's because swapout on swapfile cause file system writepage which > > makes kernel stack overflow. > > I don't *think* this is a problem unless I missed where writing out to > swap enters teh filesystem code. I'll double check. It bypasses the fs. On swapon, the blocks are resolved (mm/swapfile.c::setup_swap_extents) and then the writeout path uses bios directly (mm/page_io.c::swap_writepage). (GFP_NOFS still includes __GFP_IO, so allows swapping) Hannes -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |