linux-kernel - Re: [PATCH 5/6] syslets: add generic syslets infrastructure

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <47598FD5.3060200@oracle.com>
Date:	Fri, 07 Dec 2007 10:24:21 -0800
From:	Zach Brown <zach.brown@...cle.com>
To:	Evgeniy Polyakov <johnpol@....mipt.ru>
CC:	linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Ulrich Drepper <drepper@...hat.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Andrew Morton <akpm@....com.au>,
	Alan Cox <alan@...rguk.ukuu.org.uk>,
	"David S. Miller" <davem@...emloft.net>,
	Suparna Bhattacharya <suparna@...ibm.com>,
	Davide Libenzi <davidel@...ilserver.org>,
	Jens Axboe <jens.axboe@...cle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Dan Williams <dan.j.williams@...il.com>,
	Jeff Moyer <jmoyer@...hat.com>,
	Simon Holm Thogersen <odie@...aau.dk>,
	suresh.b.siddha@...el.com
Subject: Re: [PATCH 5/6] syslets: add generic syslets infrastructure


>> +/*
>> + * syslet_ring doesn't have any kernel-side storage.  Userspace allocates them
>> + * in their address space and initializes their fields and then passes them to
>> + * the kernel.
>> + *
>> + * These hashes provide the kernel-side storage for the wait queues which
>> + * sys_syslet_ring_wait() uses and the mutex which completion uses to serialize
>> + * the (possible blocking) ordered writes of the completion and kernel head
>> + * index into the ring.
>> + *
>> + * We chose the bucket that supports a given ring by hashing a u32 that
>> + * userspace sets in the ring.
>> + */
>> +#define SYSLET_HASH_BITS (CONFIG_BASE_SMALL ? 4 : 8)
>> +#define SYSLET_HASH_NR (1 << SYSLET_HASH_BITS)
>> +#define SYSLET_HASH_MASK (SYSLET_HASH_NR - 1)
>> +static wait_queue_head_t syslet_waitqs[SYSLET_HASH_NR];
>> +static struct mutex syslet_muts[SYSLET_HASH_NR];
> 
> Why do you care about hashed tables scalability and not using trees?

Well, this notion of letting tasks safely complete to any ring they can
address is just a possibility.  We might decide that it's not worth it.
 This implementation was an easy example that borrows from the way
futexes do similar work.

I like it because you could have, say, different processes completing
into a ring in shared memory.

If we do allow this kind of flexible ring specification, it's not at all
clear that trees would be the best way to address the scalability
limits.  There are lots of possibilities, including locking the page
lock of the page which holds the head index.

- z
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/