Re: [PATCH 12/14] vmscan: Do not writeback pages in direct reclaim

[Mel Gorman]

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@xxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/