From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pavel Machek Subject: Re: [PATCH v2 0/5] Introduce MADV_COLD and MADV_PAGEOUT Date: Wed, 12 Jun 2019 12:59:45 +0200 Message-ID: <20190612105945.GA16442@amd> References: <20190610111252.239156-1-minchan@kernel.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="zYM0uCDKw75PZbzx" Return-path: Content-Disposition: inline In-Reply-To: <20190610111252.239156-1-minchan@kernel.org> Sender: linux-kernel-owner@vger.kernel.org To: Minchan Kim Cc: Andrew Morton , linux-mm , LKML , linux-api@vger.kernel.org, Michal Hocko , Johannes Weiner , Tim Murray , Joel Fernandes , Suren Baghdasaryan , Daniel Colascione , Shakeel Butt , Sonny Rao , Brian Geffon , jannh@google.com, oleg@redhat.com, christian@brauner.io, oleksandr@redhat.com, hdanton@sina.com, lizeb@google.com List-Id: linux-api@vger.kernel.org --zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi! > - Problem >=20 > Naturally, cached apps were dominant consumers of memory on the system. > However, they were not significant consumers of swap even though they are > good candidate for swap. Under investigation, swapping out only begins > once the low zone watermark is hit and kswapd wakes up, but the overall > allocation rate in the system might trip lmkd thresholds and cause a cach= ed > process to be killed(we measured performance swapping out vs. zapping the > memory by killing a process. Unsurprisingly, zapping is 10x times faster > even though we use zram which is much faster than real storage) so kill > from lmkd will often satisfy the high zone watermark, resulting in very > few pages actually being moved to swap. Is it still faster to swap-in the application than to restart it? > This approach is similar in spirit to madvise(MADV_WONTNEED), but the > information required to make the reclaim decision is not known to the app. > Instead, it is known to a centralized userspace daemon, and that daemon > must be able to initiate reclaim on its own without any app involvement. > To solve the concern, this patch introduces new syscall - >=20 > struct pr_madvise_param { > int size; /* the size of this structure */ > int cookie; /* reserved to support atomicity */ > int nr_elem; /* count of below arrary fields */ > int __user *hints; /* hints for each range */ > /* to store result of each operation */ > const struct iovec __user *results; > /* input address ranges */ > const struct iovec __user *ranges; > }; > =20 > int process_madvise(int pidfd, struct pr_madvise_param *u_param, > unsigned long flags); That's quite a complex interface. Could we simply have feel_free_to_swap_out(int pid) syscall? :-). Pavel --=20 (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blo= g.html --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAl0A2yEACgkQMOfwapXb+vK7ngCdHTHlKgNthsiwMrKqz+jDGcDZ sfAAn1C5KLFMD7cpycS9Ep2CWeYprU8B =j4LI -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--