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-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
