From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752559AbbIKRYv (ORCPT ); Fri, 11 Sep 2015 13:24:51 -0400 Received: from mezzanine.sirena.org.uk ([106.187.55.193]:60337 "EHLO mezzanine.sirena.org.uk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751514AbbIKRYu (ORCPT ); Fri, 11 Sep 2015 13:24:50 -0400 Date: Fri, 11 Sep 2015 18:24:44 +0100 From: Mark Brown To: Stephen Boyd Cc: linux-kernel@vger.kernel.org, Abhijeet Dharmapurikar Message-ID: <20150911172443.GN20922@sirena.org.uk> References: <1441913221-19622-1-git-send-email-sboyd@codeaurora.org> <20150911102858.GE12027@sirena.org.uk> <20150911161647.GB10328@codeaurora.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="WeDu0lr7bteb/II5" Content-Disposition: inline In-Reply-To: <20150911161647.GB10328@codeaurora.org> X-Cookie: Brain off-line, please wait. User-Agent: Mutt/1.5.23 (2014-03-12) X-SA-Exim-Connect-IP: 94.175.94.161 X-SA-Exim-Mail-From: broonie@sirena.org.uk Subject: Re: [PATCH] regmap: Allocate buffers with GFP_ATOMIC when fast_io == true X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on mezzanine.sirena.org.uk) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org --WeDu0lr7bteb/II5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Sep 11, 2015 at 09:16:47AM -0700, Stephen Boyd wrote: > On 09/11, Mark Brown wrote: > > Why is this needed? If something needs fast I/O it probably doesn't > > want to be going down any of the code paths that result in us doing > > allocations. I'd expect either no cache, a flat cache or setting up > > defaults at initialisation time. > We tripped over this with regmap_bulk_write() users on the SPMI > bus. How about going down the same paths as !map->can_multi_write > and map->use_single_rw if fast_io =3D=3D true? Something like this > untested patch. Hrm, OK. Bulk writes are a reasonable use case here but we should be able to do better... if we had a cache we could bulk write directly =66rom the cache but I don't think the SPMI devices tend to have caches so that won't help. > - map->use_single_rw =3D config->use_single_rw; > - map->can_multi_write =3D config->can_multi_write; > + map->use_single_rw =3D config->use_single_rw || config->fast_io; > + map->can_multi_write =3D config->can_multi_write && !config->fast_io; The trouble with this is that you end up doing register at a time writes which isn't ideal for performance. Unless we can figure out a way to reliably allocate a bigger buffer ahead of time which I can't think of a way to do reliably without just putting a random number in the config (that we then end up either hitting or making too big) I think this is actually a reasonable use case. =20 Can you redo your patch to touch only the allocations in your data paths (I'm thinking particularly of the async changes as being unneeded, now I look again you didn't touch the cache code anyway) and put a comment in there about the alloc flags being used in fast path cases please? --WeDu0lr7bteb/II5 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV8w5bAAoJECTWi3JdVIfQo28IAISdX/T/buizxJ1/KI8rIc2f WooN+NVmwxMjDHjthbsT+Jutie5JrLD4xlXCMxrUQlbG4rwoDOp1Hue2bu5EEfkB D508pDJOG67lG3XP6g937UrH6X6+80tiEVAhacTle0TRRAG636cDXq2x6cayCm/o aJK0kGJUQidXkBkBAYRCae1/RuQ8/gqfB9cTIlfPZV3Ab70hea8bwphnZKlZE4fv PXLySqwmDVc4z1dHRTzyc1OUsHIoFiXFXdNtiEsQ8dfygGQ80TmDDfcDizZOBkMs 16GVlXXsIlFZmxejVepIDSlIq1RU/Vap7CiD+R15SZbtcuqjp7/XLD/eKsF0cIg= =8LN3 -----END PGP SIGNATURE----- --WeDu0lr7bteb/II5--