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 38564C433FE for ; Fri, 4 Nov 2022 17:15:30 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 57AB76B0071; Fri, 4 Nov 2022 13:15:29 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 52A878E0002; Fri, 4 Nov 2022 13:15:29 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 419108E0001; Fri, 4 Nov 2022 13:15:29 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 351596B0071 for ; Fri, 4 Nov 2022 13:15:29 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 04E80411F9 for ; Fri, 4 Nov 2022 17:15:28 +0000 (UTC) X-FDA: 80096411178.10.0BD11FB Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) by imf17.hostedemail.com (Postfix) with ESMTP id 852994000B for ; Fri, 4 Nov 2022 17:15:28 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id i12so3634117qvs.2 for ; Fri, 04 Nov 2022 10:15:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=3HUn0bx/DAdGh10erDX6/ij0JMTkQvrZRJ0YE9oyOkg=; b=NRUvfFrDFHOS0DexelZeJzCweg+FOTiOHPh4mO/e5pN+PvA2OQBrv+Abt7svyOW3sY f2GMbHGcprDFQDdi6ml/VW3skdY1t8KuguOR6TfcMgi4Unm+Sw46QMJL/NVwXnPEYDS5 5sHLJKU0WuCEL0dz78hapCmxnIaZgfpGnVlv4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3HUn0bx/DAdGh10erDX6/ij0JMTkQvrZRJ0YE9oyOkg=; b=sMP6b5UHm9T0dtpk+RICxzkFc1p4rB6HQmDR+YcTjt964wFXLnv40QPtCc1DKi4K9w xcwTdUekjZwqidof4gjNc0i0H9Mvjg46/iWizzqNp9iKk9tXImkvU4hHqPSOocpGZqqA LgH0cG6cKcB0nlEhG6h4eAfKqWlFnItdKBNvORKuXF2kWFJ8Njomf5xi5SKN5+nIIj76 rsqhdEb30k7V/sd0FDfCCXUMZEcaE6QoDRLDrs04v5V/iret7KQao7bMOmUG4GCu+e+I 9zciBQQyURSvMlH3tOjineaPOfGRJgQZzdpsTzYrRuHDV/BbSRsD6UdKwqB0Jn/iA9n+ ZzbA== X-Gm-Message-State: ACrzQf3pzWsgwKL7+6c1yq49bpsARQ/mLbo1iFc82uUTj0c9rDq5q3TA F3c4EWYESFrTRHNhXGQcxu4TpNkWMYmyPQ== X-Google-Smtp-Source: AMsMyM5xkvzxwPDnVwJQSDHuqgnPY31V9qRP7NlUrCtMeHBNRkF/dO0xIkio3pugxeKsv92bb+JI9w== X-Received: by 2002:a05:6214:29ec:b0:4bb:f102:de82 with SMTP id jv12-20020a05621429ec00b004bbf102de82mr26686066qvb.22.1667582127353; Fri, 04 Nov 2022 10:15:27 -0700 (PDT) Received: from mail-yw1-f171.google.com (mail-yw1-f171.google.com. [209.85.128.171]) by smtp.gmail.com with ESMTPSA id k16-20020a05620a139000b006aedb35d8a1sm3197362qki.74.2022.11.04.10.15.25 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Nov 2022 10:15:25 -0700 (PDT) Received: by mail-yw1-f171.google.com with SMTP id 00721157ae682-333a4a5d495so49321747b3.10 for ; Fri, 04 Nov 2022 10:15:25 -0700 (PDT) X-Received: by 2002:a81:114e:0:b0:36a:fc80:fa62 with SMTP id 75-20020a81114e000000b0036afc80fa62mr36113103ywr.58.1667582124813; Fri, 04 Nov 2022 10:15:24 -0700 (PDT) MIME-Version: 1.0 References: <20221022111403.531902164@infradead.org> <20221022114425.168036718@infradead.org> In-Reply-To: From: Linus Torvalds Date: Fri, 4 Nov 2022 10:15:08 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 11/13] x86_64: Remove pointless set_64bit() usage To: Peter Zijlstra Cc: Nathan Chancellor , Uros Bizjak , x86@kernel.org, willy@infradead.org, akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, aarcange@redhat.com, kirill.shutemov@linux.intel.com, jroedel@suse.de Content-Type: text/plain; charset="UTF-8" ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1667582128; a=rsa-sha256; cv=none; b=wYURBCrCRUXu15JsaeW5Wu8t27AyMf42E/YSFyroCdK+Auo38UvIrQWi3dotQEjj5aVPEx FRyAnBW915r93+6OnvhsUNxJJle7kzPYVai+oVJfpL42erJ8G92qHxpgL4sJzlWJpVr7wI LCThZgwlHNuGrP1Xe7MGRALcaw1ICeA= ARC-Authentication-Results: i=1; imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NRUvfFrD; dmarc=none; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1667582128; 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: in-reply-to:in-reply-to:references:references:dkim-signature; bh=3HUn0bx/DAdGh10erDX6/ij0JMTkQvrZRJ0YE9oyOkg=; b=QDY7x7ce24GnU4STi7JR51Hsynjstb9ppsrcWMndq1u78kAN5WvHJAethEMIyvNn3uleTJ 2nwxu+SqfofN9iuCUkozz55Y1aCmpTC1/0mk61hc9rX2xgAjMzz3dkjQ679BQmqC2LYT7l vc8V0TEZyYkuEoaPiAgQzNoOpagGe4c= X-Stat-Signature: ixo9stf653ofm9rdpp3cnirmjbnhno74 X-Rspamd-Queue-Id: 852994000B Authentication-Results: imf17.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=google header.b=NRUvfFrD; dmarc=none; spf=pass (imf17.hostedemail.com: domain of torvalds@linuxfoundation.org designates 209.85.219.53 as permitted sender) smtp.mailfrom=torvalds@linuxfoundation.org X-Rspam-User: X-Rspamd-Server: rspam07 X-HE-Tag: 1667582128-177815 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: On Fri, Nov 4, 2022 at 9:01 AM Peter Zijlstra wrote: > > So cmpxchg_double() does a cmpxchg on a double long value and is > currently supported by: i386, x86_64, arm64 and s390. > > On all those, except i386, two longs are u128. > > So how about we introduce u128 and cmpxchg128 -- then it directly > mirrors the u64 and cmpxchg64 usage we already have. It then also > naturally imposses the alignment thing. Ack, except that we might have some "u128" users that do *not* necessarily want any alignment thing. But maybe we could at least start with an u128 type that is marked as being fully aligned, and if some other user comes in down the line that wants relaxed alignment we can call it "u128_unaligned" or something. That would have avoided the pain we have on x86-32 where "u64" in a UAPI structure is differently aligned than it is on actual 64-bit architectures. > Of those slub.c is the only one that cares about 32bit and would need > some 'compat' code to pick between cmpxchg64 / cmpxchg128, but it > already has everything wrapped in helpers so that shouldn't be too big > of a worry. Ack. Special case, and we can call it something very clear, and in fact it would clean up the slab code too if we actually used some explicit type for this. Right now, slab does /* Double-word boundary */ void *freelist; /* first free object */ union { unsigned long counters; struct { where the alignment constraints are just a comment, and then it passes pointers to the two words around manually. But it should be fairly straightforward to make it use an actual properly typed thing, and using an unnamed union member, do something that takes an explicitly aligned "two word" thing instead. IOW, make the 'compat' case *not* use those stupid two separate pointers (that have to be consecutive and aligned), but actually do something like struct cmpxchg_double_long { unsigned long a,b; } __aligned(2*sizeof(long)); and then the slab case can use that union of that and the existing "freelist+word-union" to make this all not just a comment to people, but something the compiler sees too. Linus