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 Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id DBC35C35274 for ; Thu, 21 Dec 2023 18:14:37 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 796B56B008C; Thu, 21 Dec 2023 13:14:37 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 747866B0092; Thu, 21 Dec 2023 13:14:37 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 635C66B0093; Thu, 21 Dec 2023 13:14:37 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 549346B008C for ; Thu, 21 Dec 2023 13:14:37 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 19D0240477 for ; Thu, 21 Dec 2023 18:14:37 +0000 (UTC) X-FDA: 81591625794.03.5DEB67D Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf26.hostedemail.com (Postfix) with ESMTP id 7417214000C for ; Thu, 21 Dec 2023 18:14:34 +0000 (UTC) Authentication-Results: imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=i3CznAUk; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1703182475; a=rsa-sha256; cv=none; b=L0qbwESZdB6KFObq3UJrX2Z7sLlfQsIXZv/vSdz1MCfLVkDY7IZVJpy5eK2qluYh8vEtA3 fiU39m0fJhGasBQtTk9jru9Al2EC36FmHwWYCrCJvYkyuUzZz0uQeemo2YItmgnw2S3zXq ZbIPQM7lTgbc+Cm5RpECYmoUNtkA26Y= ARC-Authentication-Results: i=1; imf26.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=i3CznAUk; spf=none (imf26.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1703182475; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=t5HBHPeGSvxeProudUv8xSljJIYtxHfERyQqCNBsYdA=; b=1GDU46I4cqgMO3WC1NM0TkWZ5csr1MrTqYyofK8DHEZpbHcNrZP0waLCjQKRHrRVqEJpNY NGP0HPAel+C+5Hga+ju7uMmE3+mTKQDgJ08JiBie2XtbS5F5JtQuWfQvuF0IXv7CbTFDrD kIXSFUESvbOCvWX4V/9ZSg/Rpw6Klt0= DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Transfer-Encoding: Content-Type:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Sender:Reply-To:Content-ID:Content-Description; bh=t5HBHPeGSvxeProudUv8xSljJIYtxHfERyQqCNBsYdA=; b=i3CznAUkC0tguY2eRhr9jKfe9e v8rQg+nm0gIKXwMk1UWFgfg6pY5nU7VAQZBqxP4U+wZyERar9MKtds4dCZexSth/ULVqwxmz3RN9O 3AEWzkBQHkKLHQ25JEMuPlec6G8yC7cMha1hB8ypGMmfxjVLx0GX28rTmeNDSsLD/k23WmKr6UA7G Q84TX2rWUu09G81xbYFXa9aBN4zUBmYj/O6i2+tSvgewvoy/ZmIFp6OUnmVFUKxuYvmRcOL0SEYjX +gizZCxdNavjzfg9qw7tTlqHyO2D+vaHHPyEoncjMpoI6brE8DNTEWdbLbd2UdMLHln/Pgkb29VCX jaRrCm3w==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1rGNYg-005pk2-0f; Thu, 21 Dec 2023 18:14:10 +0000 Date: Thu, 21 Dec 2023 18:14:09 +0000 From: Matthew Wilcox To: Yang Shi Cc: Yin Fengwei , kernel test robot , Rik van Riel , oe-lkp@lists.linux.dev, lkp@intel.com, Linux Memory Management List , Andrew Morton , Christopher Lameter , ying.huang@intel.com, feng.tang@intel.com Subject: Re: [linux-next:master] [mm] 1111d46b5c: stress-ng.pthread.ops_per_sec -84.3% regression Message-ID: References: <202312192310.56367035-oliver.sang@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: 7417214000C X-Stat-Signature: 6fk4g1zqaqznxoegjptuf9nc49ddpog7 X-Rspam-User: X-HE-Tag: 1703182474-779023 X-HE-Meta: U2FsdGVkX18P3P/iXYLwyHP/tQgqXr0+B0MzaslanRvQlfM3qJ9hk2RS3UxcjJmNwYGnG4+92Ht/AqY+6y++m+NjpiyrHHO2AG4N45BhlccrXPs56RnKIYg5YbCmM+HEvWSxkfatPGl/c3MuVPXktuYYMEoaHPJAWv4g591wqQnScg5WpWxcIGki18phWZZPenl53hv0lGAmfoP/17mmQTYHt9mZgWFWFHZU5gu8CA2qY6fSitznCI/tuj/kVpW6hWpr2RWWi5yfKxbSLtrsK6ymxnogWsfD+mMqkevYnlFP6RcPkQayc+/S314NhJ+m4nhSj9RIcG04RLAh65oh4kwVRFgx/1kyzZicIhTROTMwvLpd6SHyNJFKXbkwS9DHuL4p4mdeXzhGke4667VN26dK7SObkIzxby/kicN2D8XICoy3xtTBhF5v5wK6nKgVekUIYMXcZmiRmlVeJ7XLAn6s/9GPjDHcplie2v3oK6U7wcrDGydqkhEDCGphJHXKT2yLtCuvIwzJ1fAoAKNORjOQDv5LqWgTJWezshZgeeJE1lRM8S27C6RNQOdeRPI5m4SFlvsF7RQfkAM/qHnwoBMyOGwI73tZi8+nki77NfK0gKqV99YfsMcocWSCm4fWk56dAZCnUXw+Gmp965ohnlOVNnkLzwtw2JeH9Os3a83e1711ImquTS9MzOx9yBpWXoJj0bSJpzEQmbZ3yoSjELUW5gN9O3+/WqwBh9bt375umpI6abLw0Rj9h34QnnppXMoEEf9kEv1ZW8BL2WGyzgJm1p1kURcMkqrvUQPZBaDu+TrUbvSsxFB04EjZhxzYELxzDqH+QMYPq+LsWrL7dRI4/zAM5lq18dr512VnyaiS8d2zfXT0Nl2o2htGuQ4I5r+ho6TSDHZgIa62PD14aXisvvAj8k8+TG+wTuWUARuxjDRJNBO4wT0KvRG1byFROZOUjcCupabqkKUBlEh pGKPjYFI /EnUqSKpd9WC1xvLPIyHtfI6Ux2ing8AJc3xWTdM71fp7PenJH0QqLaoTR+F39cY7vX26i0DfTUhbYfp9WSm3W/HlyGgdjkxJ0ptjUOu5EVkMb/8Vt+0KY/wXDqaJhDbfzNN9Vb2d7TmBsEUpwEH2WanyeQr1BNvrfFA9V1ys0GUA0nELgA/Lj3GjXqAk/oAPWR5ErQhxWYXnXy0TBfbdPmd05+voUQM7Fo/QYcNLhUsu6JMIjhJvuIB1gg== 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: List-Subscribe: List-Unsubscribe: On Thu, Dec 21, 2023 at 10:07:09AM -0800, Yang Shi wrote: > On Wed, Dec 20, 2023 at 8:49 PM Matthew Wilcox wrote: > > > > On Thu, Dec 21, 2023 at 08:58:42AM +0800, Yin Fengwei wrote: > > > Yes. MAP_STACK is also mentioned in manpage of mmap. I did test to > > > filter out of the MAP_STACK mapping based on this patch. The regression > > > in stress-ng.pthread was gone. I suppose this is kind of safe because > > > the madvise call is only applied to glibc allocated stack. > > > > > > > > > But what I am not sure was whether it's worthy to do such kind of change > > > as the regression only is seen obviously in micro-benchmark. No evidence > > > showed the other regressionsin this report is related with madvise. At > > > least from the perf statstics. Need to check more on stream/ramspeed. > > > > FWIW, we had a customer report a significant performance problem when > > inadvertently using 2MB pages for stacks. They were able to avoid it by > > using 2044KiB sized stacks ... > > Thanks for the report. This provided more justification regarding > honoring MAP_STACK on Linux. Some applications, for example, pthread, > just allocate a fixed size area for stack. This confuses kernel > because kernel tell stack by VM_GROWSDOWN | VM_GROWSUP. > > But I'm still a little confused by why THP for stack could result in > significant performance problems. Unless the applications resize the > stack quite often. We didn't delve into what was causing the problem, only that it was happening. The application had many threads, so it could have been as simple as consuming all the available THP and leaving fewer available for other uses. Or it could have been a memory consumption problem; maybe the app would only have been using 16-32kB per thread but was now using 2MB per thread and if there were, say, 100 threads, that's an extra 199MB of memory in use.