Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp2259698ybl; Sat, 31 Aug 2019 11:04:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhKHbyxCKwBkmX38JAKX9xdrm5QAxd1m/icgnZaNyIejVNv7bdZyEZRhDlA0mfdN8cb+WR X-Received: by 2002:a63:d84e:: with SMTP id k14mr18166575pgj.234.1567274693334; Sat, 31 Aug 2019 11:04:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567274693; cv=none; d=google.com; s=arc-20160816; b=ZtjqRDYiGrl2PCczZGiLKSzSM9IFog3mWVsIvv7uHCFRR9CmZvf3HK6DatkmITQT4T 7Pg1ztFpM6alGInSbECdQh2v4XV4E2qShIkYW9palK/EYxmWvuqhI+pE4bDNjED+CQbR YNit3lRBvh3d5PQ4YZmjvhQvNvIfWL07rjYyXgFXwhiEhUR5Tfl0uqkjUTuOjBnGxk9I 6wBj8n+en1HppGiuC13R9UMFVn8WMLj37Ez6+nVcF5ZtsjqZzlyLMCGpQ6NnbeGnjgwp 1AqFW4V+6jG4CGKZYLR0TlDSJvzTDnSVP0tyh0CDTUUHSonYSmHZ2v7vbt8Y6OqjT3w5 3ZaA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=MEkIoyBdDMi3mmN/gC/44kjAiDhXavScHt/bgtdCqm4=; b=CmLcqZdUmxIxXEC1scPE0AD8FD8dxwNczp891w8uvtzDSy5DCa7DKq3vjV9YRcIULM IJf2GWwgLlBEfZEO7AJB/K2Q5/wOPeN5p6KTaF/sV3iX/6eq1F9zojXjgPsH+x9uphyJ 8y8HqfTUzks0x1D1jt/afEqvqfohjMj7meisSjt8TlhL3I/Hw+osGzjvDBQt5OTpgCzo EPaOsnK6DVz5IXlM2W2Or0dj6jyPss2TXmyXzHKuAbLrF9PQfeAcKt3+1tifLhRiZZzN aHGWLOAy6NDZxE5AvZIUtap7JzistS7EZPRrvyKjoD+1xUSCfwXyZburR4oNhhztEws2 W5dA== ARC-Authentication-Results: i=1; mx.google.com; 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 r3si7983426plb.14.2019.08.31.11.04.37; Sat, 31 Aug 2019 11:04:53 -0700 (PDT) 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; 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 S1728527AbfHaSDY convert rfc822-to-8bit (ORCPT + 99 others); Sat, 31 Aug 2019 14:03:24 -0400 Received: from mx2.suse.de ([195.135.220.15]:37242 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726705AbfHaSDY (ORCPT ); Sat, 31 Aug 2019 14:03:24 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 11A4BAFCF; Sat, 31 Aug 2019 18:03:22 +0000 (UTC) Date: Sat, 31 Aug 2019 20:03:18 +0200 From: Michal =?UTF-8?B?U3VjaMOhbmVr?= To: Christophe Leroy Cc: linuxppc-dev@lists.ozlabs.org, Madhavan Srinivasan , David Hildenbrand , Heiko Carstens , Paul Mackerras , Breno Leitao , Michael Neuling , Diana Craciun , Firoz Khan , Hari Bathini , Joel Stanley , Arnd Bergmann , Nicholas Piggin , Alexander Viro , Thomas Gleixner , Allison Randal , Greg Kroah-Hartman , linux-kernel@vger.kernel.org, "Eric W. Biederman" , Andrew Donnellan , linux-fsdevel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v7 0/6] Disable compat cruft on ppc64le v7 Message-ID: <20190831200318.74c32b57@naga> In-Reply-To: References: X-Mailer: Claws Mail 3.17.4 (GTK+ 2.24.32; x86_64-suse-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 31 Aug 2019 08:41:58 +0200 Christophe Leroy wrote: > Le 30/08/2019 à 23:03, Michal Suchanek a écrit : > > Less code means less bugs so add a knob to skip the compat stuff. > > I guess on PPC64 you have Gigabytes of memory and thousands of bogomips, > hence you focus on bugs. > > My main focus usually is kernel size and performance, which makes this > series interesting as well. > > Anyway, I was wondering, would it make sense (in a following series, not > in this one) to make it buildable as a module, just like some of binfmt ? I think not. You have the case when 32bit support is not optional because you are 32bit and when it is optional because you are 64bit. These cases either diverge or the 32bit case suffers the penalty of some indirection that makes the functionality loadable. The indirection requires some synchronization so the 32bit code cannot be unloaded while you are trying to call it, and possibly counting 32bit tasks so you will know when you can unload the 32bit code again. This would add more code which benefits neither performance nor size nor reliability. Also you can presumably run 32bit code with binfmt-misc already but don't get stuff like perf counters handled in the kernel because it is not native code anymore. Thanks Michal > > Christophe > > > > > This is tested on ppc64le top of > > > > https://patchwork.ozlabs.org/cover/1153556/ > > > > Changes in v2: saner CONFIG_COMPAT ifdefs > > Changes in v3: > > - change llseek to 32bit instead of builing it unconditionally in fs > > - clanup the makefile conditionals > > - remove some ifdefs or convert to IS_DEFINED where possible > > Changes in v4: > > - cleanup is_32bit_task and current_is_64bit > > - more makefile cleanup > > Changes in v5: > > - more current_is_64bit cleanup > > - split off callchain.c 32bit and 64bit parts > > Changes in v6: > > - cleanup makefile after split > > - consolidate read_user_stack_32 > > - fix some checkpatch warnings > > Changes in v7: > > - add back __ARCH_WANT_SYS_LLSEEK to fix build with llseek > > - remove leftover hunk > > - add review tags > > > > Michal Suchanek (6): > > powerpc: Add back __ARCH_WANT_SYS_LLSEEK macro > > powerpc: move common register copy functions from signal_32.c to > > signal.c > > powerpc/perf: consolidate read_user_stack_32 > > powerpc/64: make buildable without CONFIG_COMPAT > > powerpc/64: Make COMPAT user-selectable disabled on littleendian by > > default. > > powerpc/perf: split callchain.c by bitness > > > > arch/powerpc/Kconfig | 5 +- > > arch/powerpc/include/asm/thread_info.h | 4 +- > > arch/powerpc/include/asm/unistd.h | 1 + > > arch/powerpc/kernel/Makefile | 7 +- > > arch/powerpc/kernel/entry_64.S | 2 + > > arch/powerpc/kernel/signal.c | 144 +++++++++- > > arch/powerpc/kernel/signal_32.c | 140 --------- > > arch/powerpc/kernel/syscall_64.c | 6 +- > > arch/powerpc/kernel/vdso.c | 5 +- > > arch/powerpc/perf/Makefile | 5 +- > > arch/powerpc/perf/callchain.c | 377 +------------------------ > > arch/powerpc/perf/callchain.h | 11 + > > arch/powerpc/perf/callchain_32.c | 204 +++++++++++++ > > arch/powerpc/perf/callchain_64.c | 185 ++++++++++++ > > fs/read_write.c | 3 +- > > 15 files changed, 566 insertions(+), 533 deletions(-) > > create mode 100644 arch/powerpc/perf/callchain.h > > create mode 100644 arch/powerpc/perf/callchain_32.c > > create mode 100644 arch/powerpc/perf/callchain_64.c > >