From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx132.postini.com [74.125.245.132]) by kanga.kvack.org (Postfix) with SMTP id 103066B006C for ; Fri, 7 Dec 2012 18:57:14 -0500 (EST) MIME-Version: 1.0 Message-ID: Date: Fri, 7 Dec 2012 15:57:08 -0800 (PST) From: Dan Magenheimer Subject: zram /proc/swaps accounting weirdness Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Nitin Gupta , Minchan Kim Cc: Luigi Semenzato , linux-mm@kvack.org While playing around with zcache+zram (see separate thread), I was watching stats with "watch -d". It appears from the code that /sys/block/num_writes only increases, never decreases. In my test, num_writes got up to 1863. /sys/block/disksize is 104857600. I have two swap disks, one zram (pri=3D60), one real (pri=3D-1), and as a I watched /proc/swaps, the "Used" field grew rapidly and reached the Size (102396k) of the zram swap, and then the second swap disk (a physical disk partition) started being used. Then for awhile, the Used field for both swap devices was changing (up and down). Can you explain how this could happen if num_writes never exceeded 1863? This may be harmless in the case where the only swap on the system is zram; or may indicate a bug somewhere? It looks like num_writes is counting bio's not pages... which would imply the bio's are potentially quite large (and I'll guess they are of size SWAPFILE_CLUSTER which is defined to be 256). Do large clusters make sense with zram? Late on a Friday so sorry if I am incomprehensible... P.S. The corresponding stat for zcache indicates that it failed 8852 stores, so I would have expected zram to deal with no more than 8852 compressions. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx177.postini.com [74.125.245.177]) by kanga.kvack.org (Postfix) with SMTP id 8825A6B006E for ; Sun, 9 Dec 2012 22:15:58 -0500 (EST) Received: by mail-vb0-f41.google.com with SMTP id l22so2564897vbn.14 for ; Sun, 09 Dec 2012 19:15:57 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: Date: Mon, 10 Dec 2012 11:15:57 +0800 Message-ID: Subject: Re: zram /proc/swaps accounting weirdness From: Bob Liu Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Dan Magenheimer Cc: Nitin Gupta , Minchan Kim , Luigi Semenzato , linux-mm@kvack.org Hi Dan, On Sat, Dec 8, 2012 at 7:57 AM, Dan Magenheimer wrote: > While playing around with zcache+zram (see separate thread), > I was watching stats with "watch -d". > > It appears from the code that /sys/block/num_writes only > increases, never decreases. In my test, num_writes got up > to 1863. /sys/block/disksize is 104857600. > > I have two swap disks, one zram (pri=60), one real (pri=-1), > and as a I watched /proc/swaps, the "Used" field grew rapidly > and reached the Size (102396k) of the zram swap, and then > the second swap disk (a physical disk partition) started being > used. Then for awhile, the Used field for both swap devices > was changing (up and down). > > Can you explain how this could happen if num_writes never > exceeded 1863? This may be harmless in the case where > the only swap on the system is zram; or may indicate a bug > somewhere? > Sorry, I didn't get your idea here. In my opinion, num_writes is the count of request but not the size. I think the total size should be the sum of bio->bi_size, so if num_writes is 1863 the actual size may also exceed 102396k. > It looks like num_writes is counting bio's not pages... > which would imply the bio's are potentially quite large > (and I'll guess they are of size SWAPFILE_CLUSTER which is > defined to be 256). Do large clusters make sense with zram? > > Late on a Friday so sorry if I am incomprehensible... > > P.S. The corresponding stat for zcache indicates that > it failed 8852 stores, so I would have expected zram > to deal with no more than 8852 compressions. > -- Regards, --Bob -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx105.postini.com [74.125.245.105]) by kanga.kvack.org (Postfix) with SMTP id 8179F6B0074 for ; Tue, 11 Dec 2012 01:26:04 -0500 (EST) Date: Tue, 11 Dec 2012 15:26:01 +0900 From: Minchan Kim Subject: Re: zram /proc/swaps accounting weirdness Message-ID: <20121211062601.GD22698@blaptop> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Dan Magenheimer Cc: Nitin Gupta , Luigi Semenzato , linux-mm@kvack.org Hi Dan, On Fri, Dec 07, 2012 at 03:57:08PM -0800, Dan Magenheimer wrote: > While playing around with zcache+zram (see separate thread), > I was watching stats with "watch -d". > > It appears from the code that /sys/block/num_writes only > increases, never decreases. In my test, num_writes got up Never decreasement is natural. > to 1863. /sys/block/disksize is 104857600. > > I have two swap disks, one zram (pri=60), one real (pri=-1), > and as a I watched /proc/swaps, the "Used" field grew rapidly > and reached the Size (102396k) of the zram swap, and then > the second swap disk (a physical disk partition) started being > used. Then for awhile, the Used field for both swap devices > was changing (up and down). > > Can you explain how this could happen if num_writes never > exceeded 1863? This may be harmless in the case where Odd. I tried to reproduce it with zram and real swap device without zcache but failed. Does the problem happen only if enabling zcache together? > the only swap on the system is zram; or may indicate a bug > somewhere? > > It looks like num_writes is counting bio's not pages... > which would imply the bio's are potentially quite large > (and I'll guess they are of size SWAPFILE_CLUSTER which is > defined to be 256). Do large clusters make sense with zram? Swap_writepage handles a page and zram_make_request doesn't use pluging mechanism of block I/O. So every request for swap-over-zram is a bio and a page. So your problem might be a BUG. > > Late on a Friday so sorry if I am incomprehensible... > > P.S. The corresponding stat for zcache indicates that > it failed 8852 stores, so I would have expected zram > to deal with no more than 8852 compressions. > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- Kind regards, Minchan Kim -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx145.postini.com [74.125.245.145]) by kanga.kvack.org (Postfix) with SMTP id 07BEF6B0092 for ; Tue, 11 Dec 2012 19:22:49 -0500 (EST) MIME-Version: 1.0 Message-ID: <3a344fcf-c256-42e9-87c3-66cd41d763f9@default> Date: Tue, 11 Dec 2012 16:22:40 -0800 (PST) From: Dan Magenheimer Subject: RE: zram /proc/swaps accounting weirdness References: In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Bob Liu Cc: Nitin Gupta , Minchan Kim , Luigi Semenzato , linux-mm@kvack.org > From: Bob Liu [mailto:lliubbo@gmail.com] > Subject: Re: zram /proc/swaps accounting weirdness >=20 > Hi Dan, >=20 > On Sat, Dec 8, 2012 at 7:57 AM, Dan Magenheimer > wrote: > > While playing around with zcache+zram (see separate thread), > > I was watching stats with "watch -d". > > > > It appears from the code that /sys/block/num_writes only > > increases, never decreases. In my test, num_writes got up > > to 1863. /sys/block/disksize is 104857600. > > > > I have two swap disks, one zram (pri=3D60), one real (pri=3D-1), > > and as a I watched /proc/swaps, the "Used" field grew rapidly > > and reached the Size (102396k) of the zram swap, and then > > the second swap disk (a physical disk partition) started being > > used. Then for awhile, the Used field for both swap devices > > was changing (up and down). > > > > Can you explain how this could happen if num_writes never > > exceeded 1863? This may be harmless in the case where > > the only swap on the system is zram; or may indicate a bug > > somewhere? > > >=20 > Sorry, I didn't get your idea here. > In my opinion, num_writes is the count of request but not the size. > I think the total size should be the sum of bio->bi_size, > so if num_writes is 1863 the actual size may also exceed 102396k. Hi Bob -- I added some debug code to record total bio_bi_size (and some other things) to sysfs. No, bio->bi_size appears to always (or nearly always) be PAGE_SIZE. Debug patch attached below in case you are interested. (Applies to 3.7 final.) > > It looks like num_writes is counting bio's not pages... > > which would imply the bio's are potentially quite large > > (and I'll guess they are of size SWAPFILE_CLUSTER which is > > defined to be 256). Do large clusters make sense with zram? > > > > Late on a Friday so sorry if I am incomprehensible... > > > > P.S. The corresponding stat for zcache indicates that > > it failed 8852 stores, so I would have expected zram > > to deal with no more than 8852 compressions. diff --git a/drivers/staging/zram/zram_drv.c b/drivers/staging/zram/zram_dr= v.c index 6edefde..9679b02 100644 --- a/drivers/staging/zram/zram_drv.c +++ b/drivers/staging/zram/zram_drv.c @@ -160,7 +160,7 @@ static void zram_free_page(struct zram *zram, size_t in= dex) =20 =09zram_stat64_sub(zram, &zram->stats.compr_size, =09=09=09zram->table[index].size); -=09zram_stat_dec(&zram->stats.pages_stored); +=09zram_stat64_sub(zram, &zram->stats.pages_stored, -1); =20 =09zram->table[index].handle =3D 0; =09zram->table[index].size =3D 0; @@ -371,7 +371,8 @@ static int zram_bvec_write(struct zram *zram, struct bi= o_vec *bvec, u32 index, =20 =09/* Update stats */ =09zram_stat64_add(zram, &zram->stats.compr_size, clen); -=09zram_stat_inc(&zram->stats.pages_stored); +=09zram_stat64_inc(zram, &zram->stats.pages_stored); +=09zram_stat64_inc(zram, &zram->stats.cum_pages_stored); =09if (clen <=3D PAGE_SIZE / 2) =09=09zram_stat_inc(&zram->stats.good_compress); =20 @@ -419,6 +420,8 @@ static void __zram_make_request(struct zram *zram, stru= ct bio *bio, int rw) =09=09zram_stat64_inc(zram, &zram->stats.num_reads); =09=09break; =09case WRITE: +=09=09zram_stat64_add(zram, &zram->stats.tot_bio_bi_size, +=09=09=09=09bio->bi_size); =09=09zram_stat64_inc(zram, &zram->stats.num_writes); =09=09break; =09} @@ -428,6 +431,11 @@ static void __zram_make_request(struct zram *zram, str= uct bio *bio, int rw) =20 =09bio_for_each_segment(bvec, bio, i) { =09=09int max_transfer_size =3D PAGE_SIZE - offset; +=09=09switch (rw) { +=09=09case WRITE: +=09=09=09zram_stat64_inc(zram, &zram->stats.num_segments); +=09=09break; +=09=09} =20 =09=09if (bvec->bv_len > max_transfer_size) { =09=09=09/* diff --git a/drivers/staging/zram/zram_drv.h b/drivers/staging/zram/zram_dr= v.h index 572c0b1..c40fe50 100644 --- a/drivers/staging/zram/zram_drv.h +++ b/drivers/staging/zram/zram_drv.h @@ -76,12 +76,15 @@ struct zram_stats { =09u64 compr_size;=09=09/* compressed size of pages stored */ =09u64 num_reads;=09=09/* failed + successful */ =09u64 num_writes;=09=09/* --do-- */ +=09u64 tot_bio_bi_size;=09=09/* --do-- */ +=09u64 num_segments;=09=09/* --do-- */ =09u64 failed_reads;=09/* should NEVER! happen */ =09u64 failed_writes;=09/* can happen when memory is too low */ =09u64 invalid_io;=09=09/* non-page-aligned I/O requests */ =09u64 notify_free;=09/* no. of swap slot free notifications */ =09u32 pages_zero;=09=09/* no. of zero filled pages */ -=09u32 pages_stored;=09/* no. of pages currently stored */ +=09u64 pages_stored;=09/* no. of pages currently stored */ +=09u64 cum_pages_stored;=09/* pages cumulatively stored */ =09u32 good_compress;=09/* % of pages with compression ratio<=3D50% */ =09u32 bad_compress;=09/* % of pages with compression ratio>=3D75% */ }; diff --git a/drivers/staging/zram/zram_sysfs.c b/drivers/staging/zram/zram_= sysfs.c index edb0ed4..2df62d4 100644 --- a/drivers/staging/zram/zram_sysfs.c +++ b/drivers/staging/zram/zram_sysfs.c @@ -136,6 +136,42 @@ static ssize_t num_writes_show(struct device *dev, =09=09zram_stat64_read(zram, &zram->stats.num_writes)); } =20 +static ssize_t tot_bio_bi_size_show(struct device *dev, +=09=09struct device_attribute *attr, char *buf) +{ +=09struct zram *zram =3D dev_to_zram(dev); + +=09return sprintf(buf, "%llu\n", +=09=09zram_stat64_read(zram, &zram->stats.tot_bio_bi_size)); +} + +static ssize_t num_segments_show(struct device *dev, +=09=09struct device_attribute *attr, char *buf) +{ +=09struct zram *zram =3D dev_to_zram(dev); + +=09return sprintf(buf, "%llu\n", +=09=09zram_stat64_read(zram, &zram->stats.num_segments)); +} + +static ssize_t pages_stored_show(struct device *dev, +=09=09struct device_attribute *attr, char *buf) +{ +=09struct zram *zram =3D dev_to_zram(dev); + +=09return sprintf(buf, "%llu\n", +=09=09zram_stat64_read(zram, &zram->stats.pages_stored)); +} + +static ssize_t cum_pages_stored_show(struct device *dev, +=09=09struct device_attribute *attr, char *buf) +{ +=09struct zram *zram =3D dev_to_zram(dev); + +=09return sprintf(buf, "%llu\n", +=09=09zram_stat64_read(zram, &zram->stats.cum_pages_stored)); +} + static ssize_t invalid_io_show(struct device *dev, =09=09struct device_attribute *attr, char *buf) { @@ -198,6 +234,10 @@ static DEVICE_ATTR(initstate, S_IRUGO, initstate_show,= NULL); static DEVICE_ATTR(reset, S_IWUSR, NULL, reset_store); static DEVICE_ATTR(num_reads, S_IRUGO, num_reads_show, NULL); static DEVICE_ATTR(num_writes, S_IRUGO, num_writes_show, NULL); +static DEVICE_ATTR(tot_bio_bi_size, S_IRUGO, tot_bio_bi_size_show, NULL); +static DEVICE_ATTR(num_segments, S_IRUGO, num_segments_show, NULL); +static DEVICE_ATTR(pages_stored, S_IRUGO, pages_stored_show, NULL); +static DEVICE_ATTR(cum_pages_stored, S_IRUGO, cum_pages_stored_show, NULL)= ; static DEVICE_ATTR(invalid_io, S_IRUGO, invalid_io_show, NULL); static DEVICE_ATTR(notify_free, S_IRUGO, notify_free_show, NULL); static DEVICE_ATTR(zero_pages, S_IRUGO, zero_pages_show, NULL); @@ -211,6 +251,10 @@ static struct attribute *zram_disk_attrs[] =3D { =09&dev_attr_reset.attr, =09&dev_attr_num_reads.attr, =09&dev_attr_num_writes.attr, +=09&dev_attr_tot_bio_bi_size.attr, +=09&dev_attr_num_segments.attr, +=09&dev_attr_pages_stored.attr, +=09&dev_attr_cum_pages_stored.attr, =09&dev_attr_invalid_io.attr, =09&dev_attr_notify_free.attr, =09&dev_attr_zero_pages.attr, -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx107.postini.com [74.125.245.107]) by kanga.kvack.org (Postfix) with SMTP id EF9696B008A for ; Tue, 11 Dec 2012 19:34:32 -0500 (EST) MIME-Version: 1.0 Message-ID: Date: Tue, 11 Dec 2012 16:34:24 -0800 (PST) From: Dan Magenheimer Subject: RE: zram /proc/swaps accounting weirdness References: <20121211062601.GD22698@blaptop> In-Reply-To: <20121211062601.GD22698@blaptop> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Minchan Kim Cc: Nitin Gupta , Luigi Semenzato , linux-mm@kvack.org > From: Minchan Kim [mailto:minchan@kernel.org] > Subject: Re: zram /proc/swaps accounting weirdness >=20 > Hi Dan, >=20 > On Fri, Dec 07, 2012 at 03:57:08PM -0800, Dan Magenheimer wrote: > > While playing around with zcache+zram (see separate thread), > > I was watching stats with "watch -d". > > > > It appears from the code that /sys/block/num_writes only > > increases, never decreases. In my test, num_writes got up >=20 > Never decreasement is natural. Agreed. =20 > > to 1863. /sys/block/disksize is 104857600. > > > > I have two swap disks, one zram (pri=3D60), one real (pri=3D-1), > > and as a I watched /proc/swaps, the "Used" field grew rapidly > > and reached the Size (102396k) of the zram swap, and then > > the second swap disk (a physical disk partition) started being > > used. Then for awhile, the Used field for both swap devices > > was changing (up and down). > > > > Can you explain how this could happen if num_writes never > > exceeded 1863? This may be harmless in the case where >=20 > Odd. > I tried to reproduce it with zram and real swap device without > zcache but failed. Does the problem happen only if enabling zcache > together? I also cannot reproduce it with only zram, without zcache. I can only reproduce with zcache+zram. Since zcache will only "fall through" to zram when the frontswap_store() call in swap_writepage() fails, I wonder if in both cases swap_writepage() is being called in large (e.g. SWAPFILE_CLUSTER-sized) blocks of pages? When zram-only, the entire block of pages always gets sent to zram, but with zcache only a small randomly-positioned fraction fail frontswap_store(), but the SWAPFILE_CLUSTER-sized blocks have already been pre-reserved on the swap device and become only partially-filled? Thanks, Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx136.postini.com [74.125.245.136]) by kanga.kvack.org (Postfix) with SMTP id 5C61E6B002B for ; Tue, 11 Dec 2012 20:12:27 -0500 (EST) MIME-Version: 1.0 Message-ID: <9c96c9e7-4f6e-4e78-a207-009293c37b89@default> Date: Tue, 11 Dec 2012 17:12:18 -0800 (PST) From: Dan Magenheimer Subject: RE: zram /proc/swaps accounting weirdness References: <20121211062601.GD22698@blaptop> In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Dan Magenheimer , Minchan Kim Cc: Nitin Gupta , Luigi Semenzato , linux-mm@kvack.org, Bob Liu > From: Dan Magenheimer > Subject: RE: zram /proc/swaps accounting weirdness >=20 > > > Can you explain how this could happen if num_writes never > > > exceeded 1863? This may be harmless in the case where > > > > Odd. > > I tried to reproduce it with zram and real swap device without > > zcache but failed. Does the problem happen only if enabling zcache > > together? >=20 > I also cannot reproduce it with only zram, without zcache. > I can only reproduce with zcache+zram. Since zcache will > only "fall through" to zram when the frontswap_store() call > in swap_writepage() fails, I wonder if in both cases swap_writepage() > is being called in large (e.g. SWAPFILE_CLUSTER-sized) blocks > of pages? When zram-only, the entire block of pages always gets > sent to zram, but with zcache only a small randomly-positioned > fraction fail frontswap_store(), but the SWAPFILE_CLUSTER-sized > blocks have already been pre-reserved on the swap device and > become only partially-filled? Urk. Never mind. My bad. When a swap page is compressed in zcache, it gets accounted in the swap subsystem as an "inuse" page for the backing swap device. (Frontswap provides a page-by-page "fronting store" for the swap device.) That explains why Used is so high for the "zram swap device" even though zram has only compressed a fraction of the pages... the remaining (much larger) number of pages have been compressed by/in zcache. Move along, there are no droids here. :-( Dan -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx152.postini.com [74.125.245.152]) by kanga.kvack.org (Postfix) with SMTP id 3700F6B00BA for ; Sat, 16 Feb 2013 20:52:24 -0500 (EST) Received: by mail-qa0-f51.google.com with SMTP id cr7so838711qab.10 for ; Sat, 16 Feb 2013 17:52:23 -0800 (PST) Message-ID: <512037D1.2010907@gmail.com> Date: Sun, 17 Feb 2013 09:52:17 +0800 From: Simon Jeons MIME-Version: 1.0 Subject: Re: zram /proc/swaps accounting weirdness References: <20121211062601.GD22698@blaptop> <9c96c9e7-4f6e-4e78-a207-009293c37b89@default> In-Reply-To: <9c96c9e7-4f6e-4e78-a207-009293c37b89@default> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Dan Magenheimer Cc: Minchan Kim , Nitin Gupta , Luigi Semenzato , linux-mm@kvack.org, Bob Liu On 12/12/2012 09:12 AM, Dan Magenheimer wrote: >> From: Dan Magenheimer >> Subject: RE: zram /proc/swaps accounting weirdness >> >>>> Can you explain how this could happen if num_writes never >>>> exceeded 1863? This may be harmless in the case where >>> Odd. >>> I tried to reproduce it with zram and real swap device without >>> zcache but failed. Does the problem happen only if enabling zcache >>> together? >> I also cannot reproduce it with only zram, without zcache. >> I can only reproduce with zcache+zram. Since zcache will >> only "fall through" to zram when the frontswap_store() call >> in swap_writepage() fails, I wonder if in both cases swap_writepage() >> is being called in large (e.g. SWAPFILE_CLUSTER-sized) blocks >> of pages? When zram-only, the entire block of pages always gets >> sent to zram, but with zcache only a small randomly-positioned >> fraction fail frontswap_store(), but the SWAPFILE_CLUSTER-sized >> blocks have already been pre-reserved on the swap device and >> become only partially-filled? > Urk. Never mind. My bad. When a swap page is compressed in > zcache, it gets accounted in the swap subsystem as an "inuse" Could you point out to me where add this count to swap subsystem? > page for the backing swap device. (Frontswap provides a > page-by-page "fronting store" for the swap device.) That explains > why Used is so high for the "zram swap device" even though > zram has only compressed a fraction of the pages... the > remaining (much larger) number of pages have been compressed > by/in zcache. > > Move along, there are no droids here. :-( > > Dan > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@kvack.org. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Don't email: email@kvack.org -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx111.postini.com [74.125.245.111]) by kanga.kvack.org (Postfix) with SMTP id 99D846B0002 for ; Mon, 18 Feb 2013 12:54:50 -0500 (EST) MIME-Version: 1.0 Message-ID: Date: Mon, 18 Feb 2013 09:54:38 -0800 (PST) From: Dan Magenheimer Subject: RE: zram /proc/swaps accounting weirdness References: <20121211062601.GD22698@blaptop> <9c96c9e7-4f6e-4e78-a207-009293c37b89@default> <512037D1.2010907@gmail.com> In-Reply-To: <512037D1.2010907@gmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: Simon Jeons Cc: Minchan Kim , Nitin Gupta , Luigi Semenzato , linux-mm@kvack.org, Bob Liu > From: Simon Jeons [mailto:simon.jeons@gmail.com] > Subject: Re: zram /proc/swaps accounting weirdness >=20 > On 12/12/2012 09:12 AM, Dan Magenheimer wrote: > >> From: Dan Magenheimer > >> Subject: RE: zram /proc/swaps accounting weirdness > >> > >>>> Can you explain how this could happen if num_writes never > >>>> exceeded 1863? This may be harmless in the case where > >>> Odd. > >>> I tried to reproduce it with zram and real swap device without > >>> zcache but failed. Does the problem happen only if enabling zcache > >>> together? > >> I also cannot reproduce it with only zram, without zcache. > >> I can only reproduce with zcache+zram. Since zcache will > >> only "fall through" to zram when the frontswap_store() call > >> in swap_writepage() fails, I wonder if in both cases swap_writepage() > >> is being called in large (e.g. SWAPFILE_CLUSTER-sized) blocks > >> of pages? When zram-only, the entire block of pages always gets > >> sent to zram, but with zcache only a small randomly-positioned > >> fraction fail frontswap_store(), but the SWAPFILE_CLUSTER-sized > >> blocks have already been pre-reserved on the swap device and > >> become only partially-filled? > > Urk. Never mind. My bad. When a swap page is compressed in > > zcache, it gets accounted in the swap subsystem as an "inuse" >=20 > Could you point out to me where add this count to swap subsystem? The swap subsystem doesn't know whether the page is held in zcache or has been written to the swap disk, only that one of these happened. So si->inuse_pages gets incremented either way. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org