From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f54.google.com (mail-qv1-f54.google.com [209.85.219.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3FF161802AB for ; Wed, 8 Jan 2025 01:19:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736299161; cv=none; b=NYEMoSnq2GNI6MSB5foJxGpa5NWdDwp5iEm4UVAyigRDpTDn6JROkkxZwaQ5GuJbalN4aA4OAESwt6+vwUikmE8dS6xKmoae7FFvnfg6WS2mToVk9GAwuLqdRWv6z7S7ayVWDXT3RvoDWAV57gQgJmXjfOvsE95qGA00H04rbDw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736299161; c=relaxed/simple; bh=O43PpjO9+bRZRRGZM0tbNhr2og/HW2/S5M6vi13lcTU=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=G4iXjNH/zlBfJNkEWQdbGp1+nuNnMii8N0YDrltQHXSXFt1pIw5bf2TYK8zEBORMORqsijzTkZwV6O9BCusIcBxSf9/IYDMhuaR3euTwrbsYRhUMwWoi1f2ZAexW5HP1YfS05Tlum3KrGV2jaJWDYd73zjmJOSjv4wnCAiin1r4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=NxGyRQfR; arc=none smtp.client-ip=209.85.219.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="NxGyRQfR" Received: by mail-qv1-f54.google.com with SMTP id 6a1803df08f44-6dd43b08674so117304346d6.3 for ; Tue, 07 Jan 2025 17:19:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1736299156; x=1736903956; darn=vger.kernel.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Ui/nm90nu1hiwAHJrrBotziY8KnV1phLxDPsBYQHW0s=; b=NxGyRQfRZ+3uFko/8a4hJ2fxbaaQoWglTiYIUunJrC0TZu7ACypM+Ny0vmsFiByznD iFn6dtW3l3dic84ur7aqsmpRyHnEWN4QwdAeo7v7sq55xqLmecIMaN3QzgtQQEupkXcp uQDUTCkUmVVZ8Mm/dbMca/Ikbnu64eU9ZN2jIfan+Q+Zn73K6D7HvSRj88Nw2frEXXt4 mEoY3DTHpPhXEWBzdqhKyVeluKffiWS08uByGHQRn8Qwt+zZOnmHsiaQcH5ScoUkkPYt umWTCHC27kpG1LzXjohyxEG8YBM0agu/Bw5nA+z/EzQVPN45sJK0hee2q8ePesfYXZho zCIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736299156; x=1736903956; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Ui/nm90nu1hiwAHJrrBotziY8KnV1phLxDPsBYQHW0s=; b=U0nyz8scCYJZPLEEyBulynVi9b5IXXqjgY+h23f6+kCLXERuNfF2JU4g+whNYrkpDs sKio4EgE/Eq36l1nuPS4byYzMAYwIf8CkhS8spDez8TvjU2+F5UDGIAQOhW/QTpBF4IZ hU13ms3YR0afMZHkMbywQYS5rRhcjX10cGFbjXyGuMlYIqhnLB2QqqXRGbYscOTtvkLl /ekyPLT3jF7OncjVlU7eiUCINmI2LhflLmfG3zQaN19utNYAnfqjTdYGGSmGxLyteQ/Y 8D2fyU3UHxIBoCDjGKBucToUoS9RUaUmieeiUwKgR13/vVIYAO7R4I4+dtixMMmAYy+O qFaA== X-Forwarded-Encrypted: i=1; AJvYcCVFWeYy0mayqC3p6T6FKGxKt8+RfLuOKEApPZXUwXvseCoPDMXIny9XVm6Qih7SfLQHvj2QLFAWdMKNGuQ=@vger.kernel.org X-Gm-Message-State: AOJu0YyJXk1g0E/fpdNFZMFJp21dkjoyFIXSuRb0JM6APSBU/bJWjd+i rc71MuRXzCu6hLOU5pXftoQiSgazANJeVjQRKfIWa1Vu96jherUQTBJwVyIZ9rYlSTzyrsPA1ui e3YNnp8sbRWJzcaP60v0DJqNHt8JQmb/cW5z5 X-Gm-Gg: ASbGncvFHCkLiFJ3L3ExEt56i2X9g2dKdVrbszpejjMZ9EiTfbLGJ1lgXgP85y+XfZe Aq5qPydWfoDVICYl0uP/IF6Tqk76IAw5nWc87Un5GZzmfviYaewZxOMefZ8OaS+98zs6K X-Google-Smtp-Source: AGHT+IH4J2SKUpnFZyyVLN4Qg9fAKWpzHuENS2WvmbnxNJzLlL15coTgvUIzPQl02hxTPiazkkUBplmVXRb8t9+betA= X-Received: by 2002:a05:6214:240f:b0:6d8:959b:c307 with SMTP id 6a1803df08f44-6df9b1b4ff6mr24748566d6.10.1736299155963; Tue, 07 Jan 2025 17:19:15 -0800 (PST) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250107222236.2715883-1-yosryahmed@google.com> <20250107222236.2715883-2-yosryahmed@google.com> In-Reply-To: From: Yosry Ahmed Date: Tue, 7 Jan 2025 17:18:39 -0800 X-Gm-Features: AbW1kvZ69maJZ5IJd1-Eie-61nDs8BoZJ0F9xpyPZkIfZ8epOJ6RDLev_OkXxk8 Message-ID: Subject: Re: [PATCH v2 2/2] mm: zswap: disable migration while using per-CPU acomp_ctx To: "Sridhar, Kanchana P" Cc: Andrew Morton , Johannes Weiner , Nhat Pham , Chengming Zhou , Vitaly Wool , Barry Song , Sam Sun , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "stable@vger.kernel.org" Content-Type: text/plain; charset="UTF-8" [..] > > > Couple of possibly related thoughts: > > > > > > 1) I have been thinking some more about the purpose of this per-cpu > > acomp_ctx > > > mutex. It appears that the main benefit is it causes task blocked errors > > (which are > > > useful to detect problems) if any computes in the code section it covers > > take a > > > long duration. Other than that, it does not protect a resource, nor > > prevent > > > cpu offlining from deleting its containing structure. > > > > It does protect resources. Consider this case: > > - Process A runs on CPU #1, gets the acomp_ctx, and locks it, then is > > migrated to CPU #2. > > - Process B runs on CPU #1, gets the same acomp_ctx, and tries to lock > > it then waits for process A. Without the lock they would be using the > > same lock. > > > > It is also possible that process A simply gets preempted while running > > on CPU #1 by another task that also tries to use the acomp_ctx. The > > mutex also protects against this case. > > Got it, thanks for the explanations. It seems with this patch, the mutex > would be redundant in the first example. Would this also be true of the > second example where process A gets preempted? I think the mutex is still required in the second example. Migration being disabled does not prevent other processes from running on the same CPU and attempting to use the same acomp_ctx. > If not, is it worth > figuring out a solution that works for both migration and preemption? Not sure exactly what you mean here. I suspect you mean have a single mechanism to protect against concurrent usage and CPU hotunplug rather than disabling migration and having a mutex. Yeah that would be ideal, but probably not for a hotfix. > > > > > > > > > 2) Seems like the overall problem appears to be applicable to any per-cpu > > data > > > that is being used by a process, vis-a-vis cpu hotunplug. Could it be that a > > > solution in cpu hotunplug can safe-guard more generally? Really not sure > > > about the specifics of any solution, but it occurred to me that this may > > not > > > be a problem unique to zswap. > > > > Not really. Static per-CPU data and data allocated with alloc_percpu() > > should be available for all possible CPUs, regardless of whether they > > are online or not, so CPU hotunplug is not relevant. It is relevant > > here because we allocate the memory dynamically for online CPUs only > > to save memory. I am not sure how important this is as I am not aware > > what the difference between the number of online and possible CPUs can > > be in real life deployments. > > Thought I would clarify what I meant: the problem of per-cpu data that > gets allocated dynamically using cpu hotplug and deleted even while in use > by cpu hotunplug may not be unique to zswap. If so, I was wondering if > a more generic solution in the cpu hotunplug code would be feasible/worth > exploring. I didn't look too closely, if there's something out there or something can be easily developed I'd be open to updating the zswap code accordingly, but I don't have time to look into it tbh, and it's too late in the release cycle to get creative imo.