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;
Date:   Sat, 30 Mar 2019 17:16:02 GMT
From:   George Spelvin <lkml@sdf.org>
Message-Id: <201903301716.x2UHG23t020732@sdf.org>
To:     adrian.hunter@intel.com, ard.biesheuvel@linaro.org,
        benh@kernel.crashing.org, bp@alien8.de, darrick.wong@oracle.com,
        dchinner@redhat.com, dedekind1@gmail.com,
        gregkh@linuxfoundation.org, hpa@zytor.com, jlbec@evilplan.org,
        jpoimboe@redhat.com, linux-kernel@vger.kernel.org,
        linux-mtd@lists.infradead.org, linux-snps-arc@lists.infradead.org,
        linuxppc-dev@lists.ozlabs.org, lkml@sdf.org, mark@fasheh.com,
        mingo@redhat.com, mpe@ellerman.id.au,
        naveen.n.rao@linux.vnet.ibm.com, ocfs2-devel@oss.oracle.com,
        paulus@samba.org, richard@nod.at, sfr@canb.auug.org.au,
        st5pub@yandex.ru, tglx@linutronix.de, vgupta@synopsys.com,
        x86@kernel.org
Subject: Re: [PATCH 0/5] simple sort swap function usage improvements
Cc:     akpm@linux-foundation.org, amir73il@gmail.com,
        andriy.shevchenko@linux.intel.com, ashish.samant@oracle.com,
        ge.changwei@h3c.com, gustavo@embeddedor.com, jannh@google.com,
        jiang.biao2@zte.com.cn, jiangyiwen@huawei.com, jslaby@suse.cz,
        kamalesh@linux.vnet.ibm.com, keescook@chromium.org, lchen@suse.com,
        linux@rasmusvillemoes.dk, malat@debian.org, mhocko@suse.com,
        npiggin@gmail.com, peterz@infradead.org, piaojun@huawei.com,
        rppt@linux.ibm.com, yamada.masahiro@socionext.com,
        yuehaibing@huawei.com
In-Reply-To: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
References: <18626931553963861@sas1-b3ec53dbc12b.qloud-c.yandex.net>
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Great work; that is indeed a logical follow-on.

Reviewed by: George Spelvin <lkml@sdf.org>

I you feel even more ambitious, you could try impementing Rasmus
Villemoes' idea of having generic *compare* functions.  (It's on
my to-do list, but I haven't made meaningful progress yet, and I'm
happy to pawn it off.)

A significant fraction of the time, the sort key is a 4- or 8-byte
integer field in a structure at a small offset from the base or
list_head.

A function pointer < 4096 could be interpreted as encoding:
- Key size (1 bit)
- Key signedness (1 bit)
- Sort direction (1 bit)
- Offset (9 bits; +/-256 words = +/-1024 bytes, or 0..511 words from start)

With the correct level of preprocessor hackery,
SIMPLE_CMP_ASCENDING(struct type, key_field)
SIMPLE_LIST_CMP_ASCENDING(struct type, list_field, key_field)
SIMPLE_CMP_DESCENDING(struct type, key_field)
SIMPLE_LIST_CMP_DESCENDING(struct type, list_field, key_field)

could encode all that and cause a compile-time error if the key
is the wrong type or the offset is out of range.