Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Neil Brown <neilb@suse.de>
CC:     Matthew Wilcox <willy@infradead.org>,
        Bruce Fields <bfields@fieldses.org>,
        Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Mel Gorman <mgorman@suse.com>, Linux-MM <linux-mm@kvack.org>
Subject: Re: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args()
Thread-Topic: [PATCH] SUNRPC: use congestion_wait() in svc_alloc_args()
Thread-Index: AQHXotncpaMymYUO4UWd0a8FIk5gVauXJwiAgABMkICAACIbgIAAJs+AgADuHIA=
Date:   Tue, 7 Sep 2021 14:53:48 +0000
Message-ID: <8ED6E493-21A6-46BC-810A-D9DA42996979@oracle.com>
References: <163090344807.19339.10071205771966144716@noble.neil.brown.name>
 <848A6498-CFF3-4C66-AE83-959F8221E930@oracle.com>
 <YTZ4E0Zh6F/WSpy0@casper.infradead.org>
 <163096695999.2518.10383290668057550257@noble.neil.brown.name>
 <163097529362.2518.16697605173806213577@noble.neil.brown.name>
In-Reply-To: <163097529362.2518.16697605173806213577@noble.neil.brown.name>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?BBLzxQSndb5TJ2I9yIYSRSS+9Ok2amdM0TrLm9J2IW4IOjEITN+CFzYMRDc0?=
 =?us-ascii?Q?tK+Kc5AMuiRqOcWabkzyCkq/5xyYF1REwckSDvImhY1wJwoxIPFgzzg1ds1x?=
 =?us-ascii?Q?6VMTC9WGwEGg4fwXU/I6233tcF0WrlqDoViXf1uFREd/XX2sKlAyUr2kftFF?=
 =?us-ascii?Q?+zNLKJU7zdc/GTOYB62yLLHiDhasK6VHVsIdlPvUIm+a5rVxCL6rpyBaUAW5?=
 =?us-ascii?Q?dEvcK/IYOlAht/dbW339GGQavT+5uu8kM3Sw0jznlDbZ+iRyVAK0QgVWxvsC?=
 =?us-ascii?Q?U3OgwBYvo1kx9IP3mvm2Ad39C1xZuFbJIhzpAUD69V5ARNRTbNYWZ98WMuFj?=
 =?us-ascii?Q?XZg0bFP+Q4tkfS+kZmeaxs3HAVk059CJbQx0b7I8SKMTMz9d5cCXED0HnaCj?=
 =?us-ascii?Q?3yJ4iRFxNcFQoUZKCDZs8MuikCss09XIpXf/30eRuzfXpgcAvXvfgg7vzt5l?=
 =?us-ascii?Q?WwfnLb+vNk6QwTopgHO6ee3Vyzmbw0wcyYs2b7f++lstsBht+aXrkqKGA8HG?=
 =?us-ascii?Q?nm3BA8mXx3e4c5vkyV1cKm22o3Vju3doeqD4mmAjFV4g7ldFJh1HBxxZzmHO?=
 =?us-ascii?Q?OKPBAtK2VAobOyiX2vNoLP7TYEfmZMl00/BW0lMtOyEPRJ5PL912g6pMutgW?=
 =?us-ascii?Q?9Tsp402l3fA3Or3ZwK39xsdZaxSBuJmKieckSi5Fzz7r8L0Kk+WARe1u4u42?=
 =?us-ascii?Q?W2ovHNvQvP6/2R+d/5HzxG/P55LYx/XDj+pAiDjtGNX/VqpKPOnFuXJGLpBp?=
 =?us-ascii?Q?oqeSgqiQJksBrVw9UXnJGLjipQ+38k3mZNAuwyAIfcNOM3+YL72mp4XhwgU4?=
 =?us-ascii?Q?DYobF0AtXwqnylXKN61vOamAK5k5hsG9uPkigMNIrkw7ZFVPcUoJVJBOErnc?=
 =?us-ascii?Q?HrLnOTedelNiRA3POgZvekQ8HnycaFS8AOuyMpGwUXlm+4TWxcwJ+80bSFF7?=
 =?us-ascii?Q?lpffh8buJB1OL8+vrMJksYpeVNvQRfAHrnJoAAL2R79oY1/ejBBt72QrlPMg?=
 =?us-ascii?Q?A+aX+DzfPrzHm4PJADrXe3GL1Rz/CeJdlNwGc8FtS466KtaH1pfc8Fn12CqG?=
 =?us-ascii?Q?GlLrDeY8rrlIx+CtS7lUICS1s0Ip18/Yx4sxRKeHFs5txhhW4fSblD9ImU1x?=
 =?us-ascii?Q?5m5aqV42Wjod092uNY9jJ2PYhl4NQ37RRmhqpzRMTit1Kaa+fmvH71wqCAi5?=
 =?us-ascii?Q?c+zoDf444H4qiVaOsHO5tIlGWcW574/ZDlyig7eM3JRnUcAqPZs8Y4vrDgbI?=
 =?us-ascii?Q?dUEKX7f/1x2w0tYFOB6o1aQBeNi4f6zSNz6kYxgt9AL5sSF1YRpxmdFCnBZn?=
 =?us-ascii?Q?NbFg+2m2ubS7Voq708AiReNW?=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="us-ascii"
Content-ID: <317DD58F770FDF438DAF2944A8BF9F16@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB4688.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 85b08986-b70b-4f76-8e76-08d9720f4c7c
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Sep 2021 14:53:48.1220
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Ad7yLcfCeuwijjxISlodo+aFKifCw/UwlPJmxylIAKe3qr2LVzaktTYFLWrvp5gnSuVm0KZe0uJcGI3NmXSjBQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2517
X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10099 signatures=668682
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 spamscore=0 mlxlogscore=795
 adultscore=0 bulkscore=0 suspectscore=0 malwarescore=0 phishscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2108310000
 definitions=main-2109070097
X-Proofpoint-GUID: vz4stba9vGKahjEvuK2RVYmmYXy1kHzw
X-Proofpoint-ORIG-GUID: vz4stba9vGKahjEvuK2RVYmmYXy1kHzw
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Sep 6, 2021, at 8:41 PM, NeilBrown <neilb@suse.de> wrote:
>=20
> When does a single-page GFP_KERNEL allocation fail?  Ever?
>=20
> I know that if I add __GFP_NOFAIL then it won't fail and that is
> preferred to looping.
> I know that if I add __GFP_RETRY_MAILFAIL (or others) then it might
> fail.
> But that is the semantics for a plain GFP_KERNEL ??
>=20
> I recall a suggestion one that it would only fail if the process was
> being killed by the oom killer.  That seems reasonable and would suggest
> that retrying is really bad.  Is that true?
>=20
> For svc_alloc_args(), it might be better to fail and have the calling
> server thread exit.  This would need to be combined with dynamic
> thread-count management so that when a request arrived, a new thread
> might be started.

I don't immediately see a benefit to killing server threads
during periods of memory exhaustion, but sometimes I lack
imagination.


> So maybe we really don't want reclaim_progress_wait(), and all current
> callers of congestion_wait() which are just waiting for allocation to
> succeed should be either change to use __GFP_NOFAIL, or to handle
> failure.

I had completely forgotten about GFP_NOFAIL. That seems like the
preferred answer, as it avoids an arbitrary time-based wait for
a memory resource. (And maybe svc_rqst_alloc() should also get
the NOFAIL treatment?).

The question in my mind is how the new alloc_pages_bulk() will
behave when passed NOFAIL. I would expect that NOFAIL would simply
guarantee that at least one page is allocated on every call.


--
Chuck Lever