linux-kernel - Re: [PATCH] Replace completions with semaphores

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: <20080416161652.GK9191@parisc-linux.org>
Date:	Wed, 16 Apr 2008 10:16:52 -0600
From:	Matthew Wilcox <matthew@....cx>
To:	Ingo Oeser <ioe-lkml@...eria.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Bart Van Assche <bart.vanassche@...il.com>,
	Roland Dreier <rdreier@...co.com>, Ingo Molnar <mingo@...e.hu>,
	Daniel Walker <dwalker@...sta.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Replace completions with semaphores

On Wed, Apr 16, 2008 at 06:07:24PM +0200, Ingo Oeser wrote:
> Hmm, why not introduce a provide_slots(), 
> wait_for_slot() and free_slot() API?
> 
> provide_slots() :=  initialize a resource with N available slots
> wait_for_slot() :=  wait for a slot in countable resource to be free
> free_slot() :=  make a slot available
> 
> That would:
> - fit the use case nicely
> - could be optimized for countable resources
>   with upper limits
> - allow to measure slot utilization
> - ...
> - is not called semaphore :-)

The kcounter API I'm working on has something in common with this.  But
it adds the more important feature:

 - Is debuggable

I've also researched the current users of semaphores and completions and
the API has to be extended a few different ways to take account of some
reasonable usage patterns.

The basic idea is that you get back a cookie from the kcounter_claim()
which you have to hand to the kcounter_release() function so it
knows which one you released.  It's similar to mutex debugging except
that mutexes can use the thread_info pointer as an implicit cookie.
Completions and semaphores have usage patterns where the resource is
released from interrupt context.

I'm not finished yet, but this is the current API:

extern void kcounter_init(struct kcounter *kc, unsigned int count);

extern long __must_check kcounter_claim(struct kcounter *kc);
extern long __must_check kcounter_claim_interruptible(struct kcounter *kc);
extern long __must_check kcounter_claim_timeout(struct kcounter *kc,
                                                long jiffies);
extern long __must_check kcounter_claim_interruptible_timeout(
                                struct kcounter *kc, long jiffies);
extern long __must_check kcounter_try_claim(struct kcounter *kc);
extern int __must_check kcounter_has_resources(struct kcounter *kc);
extern void kcounter_release(struct kcounter *kc, long resource);

#ifdef CONFIG_DEBUG_KCOUNTER
extern void kcounter_add_resource(struct kcounter *kc);
extern int __must_check kcounter_remove_resource(struct kcounter *kc);
#else
#define kcounter_add_resource(kc)       kcounter_release(kc, 0)
#define kcounter_remove_resource(kc)    kcounter_claim(kc)
#endif
extern void kcounter_add_all_resources(struct kcounter *kc);

The kcounter_add_resource()/kcounter_remove_resource() API is for where
we're actually adding new slots rather than releasing an already-acquired
slot.  Without debugging they're the same thing, but conceptually,
they're a different thing.

> And isn't this the same problem (called scheduling) as:
> - keeping N cpus busy
> - keeping N (disk) spindles busy
> - keeping N nic transmit queues busy
> - ...

It's not nearly as complex.  Each of those uses domain-specific knowledge
to optimise the solution.

-- 
Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."
--
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/