Re: [PATCH 0/1] mm, shmem: map few pages around fault address if they are in page cache

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Mar 03, 2014 at 03:37:07PM -0800, Andrew Morton wrote:
> On Mon, 3 Mar 2014 15:29:00 -0800 Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Mon, Mar 3, 2014 at 2:38 PM, Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
> > >
> > > When the file is uncached, results are peculiar:
> > >
> > > 0.00user 2.84system 0:50.90elapsed 5%CPU (0avgtext+0avgdata 4198096maxresident)k
> > > 0inputs+0outputs (1major+49666minor)pagefaults 0swaps
> > >
> > > That's approximately 3x more minor faults.
> > 
> > This is not peculiar.
> > 
> > When the file is uncached, some pages will obviously be under IO due
> > to readahead etc. And the fault-around code very much on purpose will
> > *not* try to wait for those pages, so any busy pages will just simply
> > not be faulted-around.
> 
> Of course.
> 
> > So you should still have fewer minor faults than faulting on *every*
> > page (ie the non-fault-around case), but I would very much expect that
> > fault-around will not see the full "one sixteenth" reduction in minor
> > faults.
> > 
> > And the order of IO will not matter, since the read-ahead is
> > asynchronous wrt the page-faults.
> 
> When a pagefault hits a locked, not-uptodate page it is going to block.
> Once it wakes up we'd *like* to find lots of now-uptodate pages in
> that page's vicinity.  Obviously, that is happening, but not to the
> fullest possible extent.  We _could_ still achieve the 16x if readahead
> was cooperating in an ideal fashion.
> 
> I don't know what's going on in there to produce this consistent 3x
> factor.

In my VM numbers are different (fault in 1G):

cold cache: 2097352inputs+0outputs (2major+25048minor)pagefaults 0swaps
hot cache: 0inputs+0outputs (0major+16450minor)pagefaults 0swaps

~1.5x more page faults with cold cache comparing to hot cache.

BTW, moving do_fault_around() below __do_fault() doesn't make much better:

cold cache: 2097200inputs+0outputs (1major+24641minor)pagefaults 0swaps

-- 
 Kirill A. Shutemov

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@xxxxxxxxx.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>




[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]