This is the mail archive of the
mailing list for the glibc project.
Re: Variations of memset()
- From: Jeff Law <law at redhat dot com>
- To: Matthew Wilcox <willy at infradead dot org>, Carlos O'Donell <carlos at redhat dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 4 Aug 2017 13:14:20 -0600
- Subject: Re: Variations of memset()
- Authentication-results: sourceware.org; auth=none
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
- Authentication-results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=law at redhat dot com
- Dmarc-filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 55F7D883BC
- References: <20170804171117.GA13948@bombadil.infradead.org> <firstname.lastname@example.org> <20170804190213.GB13948@bombadil.infradead.org>
On 08/04/2017 01:02 PM, Matthew Wilcox wrote:
> On Fri, Aug 04, 2017 at 02:09:11PM -0400, Carlos O'Donell wrote:
>> On 08/04/2017 01:11 PM, Matthew Wilcox wrote:
>>> void *memset16(uint16_t *s, uint16_t v, size_t count);
>>> void *memset32(uint32_t *s, uint32_t v, size_t count);
>>> void *memset64(uint64_t *s, uint64_t v, size_t count);
>>> void *memset_s(unsigned short *p, unsigned short v, size_t count);
>>> void *memset_i(unsigned int *p, unsigned int v, size_t count);
>>> void *memset_l(unsigned long *p, unsigned long v, size_t count);
>>> void *memset_ll(unsigned long long *p, unsigned long long v, size_t count);
>>> void *memset_p(void **p, void *v, size_t count);
>> How are users expected to use these functions?
>> What current uses to users use them for?
> I've identified three places in the Linux kernel which are quite
> dissimilar that can make use of such functions.
> 1. Initialising an array of uint32_t to a particular value. This is part
> of the Symbios SCSI driver. It is initialisation code. This benefits
> from smaller code size
> 2. Decompression in the zram driver. The zram driver can compress a page
> of RAM which consists entirely of a repeated pattern (up to the size of a
> 'long'). This benefits from the speed of memset_l.
So for these cases would it make more sense for the compiler to identify
the initialization loop and have it call into the new routines in glibc
rather than changing the kernel or various applications to call those
GCC already has the ability to identify loops that boil down to a
memset. Extending that support to handle initializations using objects
> 8 bits in size would seem straighforward to me.