Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp284420imu; Thu, 20 Dec 2018 22:20:56 -0800 (PST) X-Google-Smtp-Source: ALg8bN5IW8Bg8gYUWAgKTmoMCWtiWQX7TfVWdowX41qxlGWjsYyv6eWIWGQSk01dR/70AtcALKOn X-Received: by 2002:a17:902:33c1:: with SMTP id b59mr1251535plc.220.1545373256528; Thu, 20 Dec 2018 22:20:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1545373256; cv=none; d=google.com; s=arc-20160816; b=N9EEqQODR0fcQ8vncQ9951St+L6y5nyYJZNI1T/w4qIccyEtC3WGqvKrAxtPBsP1vZ AhY4MVPA2uzLr++a6mzl0pB5jTZZgTsQQo0BWJdFhKsaMYnCO2ZqK6faSJQP002DsIIH hKDpp7UMkm4T69sR+MdfIbpsnTwHsrGFAxHk7FQBIHSAoCm066bmqZBfEz7q3x34GCPk VUKEyRu7xTrBADaGF3Dsh3AAMg+93msXa69+zxCiNKEZQgfX4IiPmTKQJfqXAhlRNVX5 k+4kphZfdSnGIeL2mTEAnLjNJOze3AQ2xLo8XLLWIXpYtjO2QBVSHWww+0x/1TGu6MnT orRQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:feedback-id:subject:cc:cc:cc:cc:cc:cc:cc :cc:cc:cc:cc:to:from:date:user-agent:message-id:dkim-signature; bh=w3aqjn3w3cXbm3egXtkjdBiFToH98vSRG9WnJxvEZPo=; b=0AFATuwgnxk6kBkpjPwFaBkISX6RQ6A27lLLf7OSh2pWHZRtZcIzhTlO3Qb7RMuZ0i zElVy6BqJeQsHK85p1kjabI1bWMWe14feyLQ1ebh8Rm7K0hHdOc4zYU0LJhRZ5VP9uJP uPEA6NktWgxYYQ8yqtPhB62/SpRTK4dLCZeCBbSqGTURjqMe6pivO/mws4VNb8Mmb9oM jAtZZtnTtXnrcy5FWON1kfT64Fu/YNhdeJI6Q+yj+DS5e86iFuRLsS+Lqp3J5dVfmONA 1B3sL8WYroXQjuxsDZUjjKXKROXpYxELRR8sooII/oPIl8r6A4l6Grs/HKm2//NcLLwn jdCA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=cVyLVlWC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t10si19994159plh.307.2018.12.20.22.20.40; Thu, 20 Dec 2018 22:20:56 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@amazonses.com header.s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug header.b=cVyLVlWC; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389298AbeLTTV4 (ORCPT + 99 others); Thu, 20 Dec 2018 14:21:56 -0500 Received: from a9-92.smtp-out.amazonses.com ([54.240.9.92]:34894 "EHLO a9-92.smtp-out.amazonses.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731103AbeLTTV4 (ORCPT ); Thu, 20 Dec 2018 14:21:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=ug7nbtf4gccmlpwj322ax3p6ow6yfsug; d=amazonses.com; t=1545333715; h=Message-Id:Date:From:To:Cc:Cc:Cc:CC:Cc:Cc:Cc:Cc:Cc:Cc:Cc:Subject:Feedback-ID; bh=ZC6NB5lKn8jM6W/kwe979AqbHeNIIEDgIRYq8F0S3jo=; b=cVyLVlWCMnX/xXwSbAOjGke/AaYduszsLs/wcSBoRGW5RCfHoQOhRZPLy65aov7v 9F/S49PS1d+goBBjMmRpktLA/MBVFqqHc031bjQtF3/MdMPm1fRkfHVEofYlextIQBK fgnfbFMt6KSXHbGnpRm3LWKe9CJGadGv7vXr+1Ps= Message-ID: <01000167cd1130c8-c9bebcb9-1f95-4f7c-b24a-90600d56c62f-000000@email.amazonses.com> User-Agent: quilt/0.65 Date: Thu, 20 Dec 2018 19:21:55 +0000 From: Christoph Lameter To: Matthew Wilcox Cc: linux-mm@kvack.org Cc: linux-kernel@vger.kernel.org Cc: Pekka Enberg CC: akpm@linux-foundation.org Cc: Mel Gorman Cc: andi@firstfloor.org Cc: Rik van Riel Cc: Dave Chinner Cc: Christoph Hellwig Cc: Michal Hocko Cc: Mike Kravetz Subject: [RFC 0/7] Slab object migration for xarray V2 X-SES-Outgoing: 2018.12.20-54.240.9.92 Feedback-ID: 1.us-east-1.fQZZZ0Xtj2+TD7V5apTT/NrT6QKuPgzCT/IC7XYgDKI=:AmazonSES Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org V1->V2: - Works now on top of 4.20-rc7 - A couple of bug fixes This is a patchset on top of Matthew Wilcox Xarray code and implements slab object migration for xarray nodes. The migration is integrated into the defragmetation and shrinking logic of the slab allocator. Defragmentation will ensure that all xarray slab pages have less objects available than specified by the slab defrag ratio. Slab shrinking will create a slab cache with optimal object density. Only one slab page will have available objects per node. To test apply this patchset and run a workload that uses lots of radix tree objects Then go to /sys/kernel/slab/radix_tree_node Inspect the number of total objects that the slab can handle cat total_objects qmdr:/sys/kernel/slab/radix_tree_node# cat objects 868 N0=448 N1=168 N2=56 N3=196 And the number of slab pages used for those cat slabs qmdr:/sys/kernel/slab/radix_tree_node# cat slabs 31 N0=16 N1=6 N2=2 N3=7 Perform a cache shrink operation echo 1 >shrink Now see how the slab has changed: qmdr:/sys/kernel/slab/radix_tree_node# cat slabs 30 N0=15 N1=6 N2=2 N3=7 qmdr:/sys/kernel/slab/radix_tree_node# cat objects 713 N0=349 N1=141 N2=52 N3=171 This is just a barebones approach using a special mode of the slab migration patchset that does not require refcounts. If this is acceptable then additional functionality can be added: 1. Migration of objects to a specific node. Not sure how to implement that. Using another sysfs field? 2. Dispersion of objects across all nodes (MPOL_INTERLEAVE) 3. Subsystems can request to move an object to a specific node. How to design such functionality best? 4. Tying into the page migration and page defragmentation logic so that so far unmovable pages that are in the way of creating a contiguous block of memory will become movable. This would mean checking for slab pages in the migration logic and calling slab to see if it can move the page by migrating all objects. This is only possible for xarray for now but it would be worthwhile to extend this to dentries and inodes.