On Tue, May 8, 2012 at 11:58 AM, mani <manishrma@xxxxxxxxx> wrote: > How about adding the AS_DMPG flag in the file -> address_space when getting > a filemap_fault() > so that we can treat the page fault pages as the high priority pages over > normal read requests. > How about changing below lines for the support of the pages those are > requested for the page fault ? > > > --- a/fs/mpage.c 2012-05-04 12:59:12.000000000 +0530 > +++ b/fs/mpage.c 2012-05-07 13:13:49.000000000 +0530 > @@ -408,6 +408,8 @@ mpage_readpages(struct address_space *ma > &last_block_in_bio, &map_bh, > &first_logical_block, > get_block); > + if(test_bit(AS_DMPG, &mapping->flags) && bio) > > + bio->bi_rw |= REQ_RW_DMPG > } > page_cache_release(page); > } > --- a/include/linux/pagemap.h 2012-05-04 12:57:35.000000000 +0530 > +++ b/include/linux/pagemap.h 2012-05-07 13:15:24.000000000 +0530 > @@ -27,6 +27,7 @@ enum mapping_flags { > #if defined (CONFIG_BD_CACHE_ENABLED) > AS_DIRECT = __GFP_BITS_SHIFT + 4, /* DIRECT_IO specified on file op > */ > #endif > + AS_DMPG = __GFP_BITS_SHIFT + 5, /* DEMAND PAGE specified on file op > */ > }; > > static inline void mapping_set_error(struct address_space *mapping, int > error) > > --- a/mm/filemap.c 2012-05-04 12:58:49.000000000 +0530 > +++ b/mm/filemap.c 2012-05-07 13:15:03.000000000 +0530 > @@ -1646,6 +1646,7 @@ int filemap_fault(struct vm_area_struct > if (offset >= size) > return VM_FAULT_SIGBUS; > > + set_bit(AS_DMPG, &file->f_mapping->flags); > /* > * Do we have something in the page cache already? > */ > > Will these changes have any adverse effect ? > Thanks for the example but I can't judge which of the two is the most elegant or acceptable to maintainers. I can test with your change and inform if it works. > Thanks & Regards > Manish > > On Mon, May 7, 2012 at 5:01 AM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: >> >> On Thu, May 03, 2012 at 07:53:00PM +0530, Venkatraman S wrote: >> > From: Ilan Smith <ilan.smith@xxxxxxxxxxx> >> > >> > Add attribute to identify demand paging requests. >> > Mark readpages with demand paging attribute. >> > >> > Signed-off-by: Ilan Smith <ilan.smith@xxxxxxxxxxx> >> > Signed-off-by: Alex Lemberg <alex.lemberg@xxxxxxxxxxx> >> > Signed-off-by: Venkatraman S <svenkatr@xxxxxx> >> > --- >> > fs/mpage.c | 2 ++ >> > include/linux/bio.h | 7 +++++++ >> > include/linux/blk_types.h | 2 ++ >> > 3 files changed, 11 insertions(+) >> > >> > diff --git a/fs/mpage.c b/fs/mpage.c >> > index 0face1c..8b144f5 100644 >> > --- a/fs/mpage.c >> > +++ b/fs/mpage.c >> > @@ -386,6 +386,8 @@ mpage_readpages(struct address_space *mapping, >> > struct list_head *pages, >> > &last_block_in_bio, &map_bh, >> > &first_logical_block, >> > get_block); >> > + if (bio) >> > + bio->bi_rw |= REQ_RW_DMPG; >> >> Have you thought about the potential for DOSing a machine >> with this? That is, user data reads can now preempt writes of any >> kind, effectively stalling writeback and memory reclaim which will >> lead to OOM situations. Or, alternatively, journal flushing will get >> stalled and no new modifications can take place until the read >> stream stops. >> >> This really seems like functionality that belongs in an IO >> scheduler so that write starvation can be avoided, not in high-level >> data read paths where we have no clue about anything else going on >> in the IO subsystem.... >> >> Cheers, >> >> Dave. >> -- >> Dave Chinner >> david@xxxxxxxxxxxxx >> -- >> To unsubscribe from this list: send the line "unsubscribe linux-mmc" in >> the body of a message to majordomo@xxxxxxxxxxxxxxx >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- 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