From mboxrd@z Thu Jan 1 00:00:00 1970 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Jun 2017 10:27:52 +0200 (CEST) Received: from localhost.localdomain ([127.0.0.1]:34636 "EHLO linux-mips.org" rhost-flags-OK-OK-OK-FAIL) by eddie.linux-mips.org with ESMTP id S23990522AbdFLI1o2nVAL (ORCPT ); Mon, 12 Jun 2017 10:27:44 +0200 Received: from h7.dl5rb.org.uk (localhost [127.0.0.1]) by h7.dl5rb.org.uk (8.15.2/8.14.8) with ESMTP id v5C8RgXM006558; Mon, 12 Jun 2017 10:27:43 +0200 Received: (from ralf@localhost) by h7.dl5rb.org.uk (8.15.2/8.15.2/Submit) id v5C8Rg3f006557; Mon, 12 Jun 2017 10:27:42 +0200 Date: Mon, 12 Jun 2017 10:27:42 +0200 From: Ralf Baechle To: Paul Burton Cc: linux-mips@linux-mips.org Subject: Re: [PATCH 00/11] MIPS: cmpxchg(), xchg() fixes & queued locks Message-ID: <20170612082742.GA5642@linux-mips.org> References: <20170610002644.8434-1-paul.burton@imgtec.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170610002644.8434-1-paul.burton@imgtec.com> User-Agent: Mutt/1.8.0 (2017-02-23) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 58409 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk List-help: List-unsubscribe: List-software: Ecartis version 1.0.0 List-Id: linux-mips X-List-ID: linux-mips List-subscribe: List-owner: List-post: List-archive: X-list: linux-mips On Fri, Jun 09, 2017 at 05:26:32PM -0700, Paul Burton wrote: > This series makes a bunch of cleanups & improvements to the cmpxchg() & > xchg() macros & functions, allowing them to be used on values smaller > than 4 bytes, then switches MIPS over to use generic queued spinlocks & > queued read/write locks. A number of nice cleanups there! I'm wondering, have you tested the kernel size with and without this series applied? GCC claims since 25 years or so that inlines are as efficient as macros but in reality macros have always been superior which mattered for things that are expanded very often. More recent GCCs have claimed improvments so it'd be interested to see actual numbers - and possibly get rid of many more unmaintainable macros. Ralf