From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755628AbbHQQvo (ORCPT ); Mon, 17 Aug 2015 12:51:44 -0400 Received: from shadbolt.e.decadent.org.uk ([88.96.1.126]:46590 "EHLO shadbolt.e.decadent.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754608AbbHQQvn (ORCPT ); Mon, 17 Aug 2015 12:51:43 -0400 Message-ID: <1439830287.10801.28.camel@decadent.org.uk> Subject: Re: [PATCH] mm: Change global memory state symbols to GPL-only From: Ben Hutchings To: Michal Hocko Cc: Andrew Morton , LKML Date: Mon, 17 Aug 2015 18:51:27 +0200 In-Reply-To: <20150817151145.GF10894@dhcp22.suse.cz> References: <1439682147.10857.99.camel@decadent.org.uk> <20150817135448.GB10928@dhcp22.suse.cz> <1439823392.10801.16.camel@decadent.org.uk> <20150817151145.GF10894@dhcp22.suse.cz> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-DruBPLAHb5BCXH0RNkbY" X-Mailer: Evolution 3.16.3-1 Mime-Version: 1.0 X-SA-Exim-Connect-IP: 141.70.66.223 X-SA-Exim-Mail-From: ben@decadent.org.uk X-SA-Exim-Scanned: No (on shadbolt.decadent.org.uk); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --=-DruBPLAHb5BCXH0RNkbY Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2015-08-17 at 17:11 +0200, Michal Hocko wrote: > On Mon 17-08-15 16:56:32, Ben Hutchings wrote: > > On Mon, 2015-08-17 at 15:54 +0200, Michal Hocko wrote: > > > On Sun 16-08-15 01:42:27, Ben Hutchings wrote: > > > > Proprietary modules should not be able to touch vm_stat or particip= ate > > > > in shrinking. > > >=20 > > > How does the external and !GPL fs does slab reclaim? Those are essent= ial > > > for the proper memory balancing. > >=20 > > If they know how to do shrinking on Linux then they are probably > > derivative works of Linux. >=20 > I am not sure I understand. They are shrinking their internal cached > objects and that is hardly a derivative work. The shrinker API is only > meant to let them know _when_ this should happen and the interface is > a pretty much simple callback API. It is a Linux-specific API and I don't think other kernels provide something similar to loadable modules. It enables a module to turn a large part of the system RAM into a cache and have the MM effectively tell it the correct size of that cache, thus tightly integrating with global memory management. It seemed to me that this met the test for 'should this be EXPORT_SYMBOL_GPL'. > I do not want to defend a proprietary code here but this sounds like an > obstruction for those modules which will lead into a worse code in the > end because they should somehow manage the cache and it is much better > when the core (MM) tells them when it makes sense rather than external > heuristics. Yes, that's the idea, proprietary code should not be helped in this way. Ben. --=20 Ben Hutchings [W]e found...that it wasn't as easy to get programs right as we had thought= . ... I realized that a large part of my life from then on was going to be sp= ent in finding mistakes in my own programs. - Maurice Wilkes, 1949 --=-DruBPLAHb5BCXH0RNkbY Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIVAwUAVdIRD+e/yOyVhhEJAQr+uQ//a4cupdn/meooKLr3YM2qqsJ4pVZjSd1s 6VVfBhm6cAuwexyOqy2M0y1txjQpWQzv8jsfxZer+5kRCZwJ+gPCSpL8CXfDKKxQ ukUgzmdavN7TUK5i4VK6STTYpRK+wzMrKTqIxTrfOmXUfjpKrFZrikr4vhrVTljv KUCMJFXAZyLwGgErMjjcKsKTVeLNOl6j5bPfgtEJKdLaaKBLsVit2gu5UWAlmDfU w62ALmvxZ+Mvy20a+klB47xUgy8ay0LHFdlLZdDj/got5Z4Xaffo3nz1YcKIBc40 PB8vebc1K0niLUUc8QqQroYVkYMlye+xa3xr5Nqt+dGOmOrDWx4p5wHayrKN8h0L aviV0IOCLwfkw2HRI62nwOZTS1jxjQJ/8vw2WeYqv8yazFgFy4HyixX+Cb+3++kd IXMbn8Dno/g0m0YjVgyXyFwFrQRha7pPQv68KiiRd+oFx0C44hTjOfYCLmkVWBF5 ilxci+9qYpK6DBQHVf8+ISoW4bwgTpfTEjUXre1jBe0uhDZdGTlprZKGTV0/0yZv RRVqMBr/X6NKJxgC83wZuERVkG0dJDp11cBoxrTOMjWz2Qu7xC7axrELJHhIoa0C r9BV7U1zUZrhe4mzRAJrqvd0sefH444d8Wyf6/WLJMl4vQ76ynD7tGGUijW/8tU5 8y9Na8ABQQA= =EIgM -----END PGP SIGNATURE----- --=-DruBPLAHb5BCXH0RNkbY--