From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4D91DC47420 for ; Thu, 1 Oct 2020 16:17:45 +0000 (UTC) Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by mail.kernel.org (Postfix) with ESMTP id E964E208B6 for ; Thu, 1 Oct 2020 16:17:44 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="HLHjU0Ku" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org E964E208B6 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=owner-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix) id 8E1316B0074; Thu, 1 Oct 2020 12:17:44 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 891F18E0001; Thu, 1 Oct 2020 12:17:44 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 732986B0078; Thu, 1 Oct 2020 12:17:44 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id 469126B0074 for ; Thu, 1 Oct 2020 12:17:44 -0400 (EDT) Received: from smtpin08.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay05.hostedemail.com (Postfix) with ESMTP id AAE18181AE867 for ; Thu, 1 Oct 2020 16:17:43 +0000 (UTC) X-FDA: 77323862406.08.year46_39094622719c Received: from filter.hostedemail.com (10.5.16.251.rfc1918.com [10.5.16.251]) by smtpin08.hostedemail.com (Postfix) with ESMTP id 6226D1819E624 for ; Thu, 1 Oct 2020 16:17:43 +0000 (UTC) X-HE-Tag: year46_39094622719c X-Filterd-Recvd-Size: 5028 Received: from mail-oi1-f195.google.com (mail-oi1-f195.google.com [209.85.167.195]) by imf21.hostedemail.com (Postfix) with ESMTP for ; Thu, 1 Oct 2020 16:17:42 +0000 (UTC) Received: by mail-oi1-f195.google.com with SMTP id z26so6150552oih.12 for ; Thu, 01 Oct 2020 09:17:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7z4RZb4xHZvdkDhdzGHiqdJ9avmcc+//+6dEVs9Wkhw=; b=HLHjU0Kuon8b0GM8tARWJSMK6NABhtf8WNgW2nf3koqCK8mBGpp7rhE3gcWkAglCu9 bnX/O3P/ylSYBd75VPD/0dUnVOYb2HqhCykICayY8EGFOtx7K5+7U/ZnCVz/83cBh9F/ TVEsiMrDJpRi9FPKphd4dJLOUVQ1E9+ukFgleTkcpnYCOLf0FBtanbLfZnXoF4Xn0nGZ 1zVRxK6H6Ja1UjuZBXU1t/vAxI/KZSS/fSZxprO/FgCIdj5Gnh7kWhQF76a5oF0GWdjf F5XOSpT/oPmpSi9pfWF9zGXccvZ3HxCNUCgqFHUtDDIkVeqeIYlPYWv7BvfhEg/2NZYp tsVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7z4RZb4xHZvdkDhdzGHiqdJ9avmcc+//+6dEVs9Wkhw=; b=bTJkxqHGJ4BlRhDdVhCXsdUA93+eyk0KpZ+/65VHAk2K7WWUqoUyZnKgbJP7LJ4PZF 6xlqSs1KviZKO0klKPjcsxHIbRHtHfyjkQEWQErVBD039r+AfH9zJQp/zVr/RwDjaDb2 QN7BAGtMkjHlHcJnPrJfyev2P6ShsKUesKhKoy5yOXnzZrZbWuFZLyV0NDNPxd57TK3y 8Cr7eP1LBmvG59SEH/ryft0qwbIV6INztl629RLogyP7i6/y3PFFj9Rq+l9nqQjujdPO uRG4/96R95Vww+g5ExS58hHbColBE62kE2foaH2y6gRAzDNq1tkxwPMs4CrKvUdfYdRH tz6Q== X-Gm-Message-State: AOAM5328pZ2/hDjNwSqoqOiQogutf7sWslB1V7X4ddskS6fFAjztOK93 TXtWdSp03T/cHIM1L0xV98GqXn/1dTqGqgLtnTI= X-Google-Smtp-Source: ABdhPJzKVlVxbmrcE9M01GASsemfNIdCM4TOFqmm835CPdI7Vc0+hYTPTEnqy9IjIyR2jcBm4Wf9GBvDjq07pW69+80= X-Received: by 2002:aca:4142:: with SMTP id o63mr420130oia.167.1601569061882; Thu, 01 Oct 2020 09:17:41 -0700 (PDT) MIME-Version: 1.0 References: <20201001123032.GC22560@dhcp22.suse.cz> In-Reply-To: <20201001123032.GC22560@dhcp22.suse.cz> From: Sebastiaan Meijer Date: Thu, 1 Oct 2020 18:18:10 +0200 Message-ID: Subject: Re: [RFC PATCH 1/1] vmscan: Support multiple kswapd threads per node To: Michal Hocko Cc: akpm@linux-foundation.org, buddy.lumpkin@oracle.com, hannes@cmpxchg.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mgorman@suse.de, riel@surriel.com, willy@infradead.org Content-Type: text/plain; charset="UTF-8" X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: (Apologies for messing up the mailing list thread, Gmail had fooled me into believing that it properly picked up the thread) On Thu, 1 Oct 2020 at 14:30, Michal Hocko wrote: > > On Wed 30-09-20 21:27:12, Sebastiaan Meijer wrote: > > > yes it shows the bottleneck but it is quite artificial. Read data is > > > usually processed and/or written back and that changes the picture a > > > lot. > > Apologies for reviving an ancient thread (and apologies in advance for my lack > > of knowledge on how mailing lists work), but I'd like to offer up another > > reason why merging this might be a good idea. > > > > From what I understand, zswap runs its compression on the same kswapd thread, > > limiting it to a single thread for compression. Given enough processing power, > > zswap can get great throughput using heavier compression algorithms like zstd, > > but this is currently greatly limited by the lack of threading. > > Isn't this a problem of the zswap implementation rather than general > kswapd reclaim? Why zswap doesn't do the same as normal swap out in a > context outside of the reclaim? I wouldn't be able to tell you, the documentation on zswap is fairly limited from what I've found. > My recollection of the particular patch is dimm but I do remember it > tried to add more kswapd threads which would just paper over the problem > you are seein rather than solve it. Yeah, that's exactly what it does, just adding more kswap threads. I've tried updating the patch to the latest mainline kernel to test its viability for our use case, but the kswap code changed too much over the past 2 years, updating it is beyond my ability right now it seems. For the time being I've switched over to zram, which better suits our use case either way, and is threaded, but lacks zswap's memory deduplication. Even with zram I'm still seeing kswap frequently max out a core though, so there's definitely still a case for further optimization of kswap. In our case it's not a single big application taking up our memory, rather we are running 2000 high-memory applications. They store a lot of data in swap, but rarely ever access said data, so the actual swap i/o isn't even that high. -- Sebastiaan Meijer