Hi Luigi, On Fri, May 26, 2017 at 11:43:48AM -0700, Luigi Semenzato wrote: > Many thanks Minchan. > > On Thu, May 25, 2017 at 9:06 PM, Minchan Kim <minchan@xxxxxxxxxx> wrote: > > > If it is swap cache hit, it's not a major fault which causes IO > > so VM count it as minor fault, not major. > > Cool---but see below. > > > Yub, I expected you guys used zram with readahead off so it shouldn't > > be a big problem. > > By the way, I was referring to page clustering. We do this in sysctl.conf: It's readahead of swap. I meant it exactly. :) > > # Disable swap read-ahead > vm.page-cluster = 0 > > I figured that the readahead from the disk device > (/sys/block/zram0/queue/read_ahead_kb) is not meaningful---am I > correct? Yub. > > These numbers are from a Chromebook with a few dozen Chrome tabs and a > couple of Android apps, and pretty heavy use of zram. > > pgpgin 4688863 > pgpgout 442052 > pswpin 353675 > pswpout 1072021 > ... > pgfault 5564247 > pgmajfault 355758 > pgmajfault_s 6297 > pgmajfault_a 317645 > pgmajfault_f 31816 > pgmajfault_ax 8494 > pgmajfault_fx 13201 > > where _s, _a, and _f are for shmem, anon, and file pages. > (ax and fx are for the subset of executable pages---I was curious about that) > > So the numbers don't completely match: > anon faults = 318,000 > swap ins = 354,000 > > Any idea of what might explain the difference? Some of application call madvise(MADV_WILLNEED) for shmem or anon? > > > About auto resetting readahead with zram, I agree with you. > > But there are some reasons I postpone the work. No want to discuss > > it in this thread/moment. ;) > > Yes, I wasn't even thinking of auto-resetting, just log a warning. > > >> Incidentally, I understand anon and file faults, but what's a shmem fault? > > > > For me, it was out of my interest but if you want to count shmem fault, > > maybe, we need to introdue new stat(e.g., PSWPIN_SHM) in shmem_swapin > > but there are concrete reasons to justify in changelog. :) > > Actually mine was a simpler question---I have no idea what a major > shmem fault is. And for this experiment it's a relatively small > number, but a similar order of magnitude to the (expensive) file > faults, so I don't want to completely ignore it. Yes, it's doable but a thing we need to merge new stat is concrete justification rather than "Having, Better. Why not?" approach. In my testing, I just wanted to know just file vs anon LRU balancing so it was out of my interest but you might have a reason to know it. Then, you can send a patch with detailed changelog. :) Thanks. -- 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>
