> > If you do
> > (perhaps to coordinate with devices) then the barriers are required.
>
> For IO space access mb's are required, but ll/sc are of no use, AFAIK.
Ugh. You are right, of course. I forgot that drivers are also using
atomic.h, and the intelligent device could be counted as another
If you do
(perhaps to coordinate with devices) then the barriers are required.
For IO space access mb's are required, but ll/sc are of no use, AFAIK.
Ugh. You are right, of course. I forgot that drivers are also using
atomic.h, and the intelligent device could be counted as another CPU
to
On Fri, May 04, 2001 at 02:13:18PM -0700, Richard Henderson wrote:
> Eh? Would you give me an example that isn't working properly?
Sure.
bar.c:
-
extern void rarely_executed_code(void);
static inline void foo_no_be(void)
{
int ret;
__asm__ __volatile__("nop\n":
On Fri, May 04, 2001 at 02:12:40PM -0700, Richard Henderson wrote:
> > - removed some mb's for non-SMP
>
> This isn't correct. Either you need atomic updates or you don't.
> If you don't, then you shouldn't be using ll/sc at all.
I don't think so. On a single CPU system we need atomic updates
On Fri, May 04, 2001 at 02:12:40PM -0700, Richard Henderson wrote:
- removed some mb's for non-SMP
This isn't correct. Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all.
I don't think so. On a single CPU system we need atomic updates
to
On Fri, May 04, 2001 at 02:13:18PM -0700, Richard Henderson wrote:
Eh? Would you give me an example that isn't working properly?
Sure.
bar.c:
-
extern void rarely_executed_code(void);
static inline void foo_no_be(void)
{
int ret;
__asm__ __volatile__(nop\n: =r
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
> Initially I tried to use __builtin_expect in the rwsem.h, but found
> that it doesn't help at all in the small inline functions - it works
> as expected only in a reasonably large block of code.
Eh? Would you give me an example
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
> - removed some mb's for non-SMP
This isn't correct. Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all. If you do
(perhaps to coordinate with devices) then the barriers are
On Fri, May 04, 2001 at 09:02:33PM +0400, Ivan Kokshaysky wrote:
> But I can't imagine how this "feature" could be useful in a real life :-)
It will be required by the time we can fork more than 2^16 tasks (which
I'm wondering if it could be just the case if you use CLONE_PID as
root, I didn't
On Fri, May 04, 2001 at 04:33:59PM +0200, Andrea Arcangeli wrote:
> the 2^16 limit is not a per-user limit it is a global one so the max
> user process ulimit is irrelevant.
>
> Only the number of pid and the max number of tasks supported by the
> architecture is a relevant limit for this.
On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
> I don't know whether it will (a) compile, or (b) work... I don't have an alpha
> to play with.
Neither (a) nor (b) ;-) Corrected asm-alpha/rwsem.h attached.
Also small fix for lib/rwsem.c -- RWSEM_WAITING_BIAS-RWSEM_ACTIVE_BIAS
On Fri, May 04, 2001 at 01:15:28PM +0400, Ivan Kokshaysky wrote:
> However, there are 3 reasons why I prefer 16-bit counters:
I assume you mean 32bit counter. (that gives max 2^16 sleepers)
> a. "max user processes" ulimit is much lower than 64K anyway;
the 2^16 limit is not a per-user limit
On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
> Hello Ivan,
Hello David!
> I don't know whether it will (a) compile, or (b) work... I don't have an alpha
> to play with.
It looks ok at a first glance, I can try it today.
> I also don't know the alpha function calling
Hello Ivan,
One reason I picked "signed long" as the count type in the lib/rwsem.c is that
this would be 64 bits on a 64-bit arch such as the alpha.
So I've taken your idea for include/asm-alpha/rwsem.h and modified it a
little. You'll find it attached at the bottom.
I don't know whether it
On Thu, May 03, 2001 at 07:28:48PM +0200, Andrea Arcangeli wrote:
> I'd love if you could port it on top of this one and to fix it so that
> it can handle up to 2^32 sleepers and not only 2^16 like we have to do
> on the 32bit archs to get good performance:
>
>
On Thu, May 03, 2001 at 07:28:48PM +0200, Andrea Arcangeli wrote:
I'd love if you could port it on top of this one and to fix it so that
it can handle up to 2^32 sleepers and not only 2^16 like we have to do
on the 32bit archs to get good performance:
Hello Ivan,
One reason I picked signed long as the count type in the lib/rwsem.c is that
this would be 64 bits on a 64-bit arch such as the alpha.
So I've taken your idea for include/asm-alpha/rwsem.h and modified it a
little. You'll find it attached at the bottom.
I don't know whether it will
On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
Hello Ivan,
Hello David!
I don't know whether it will (a) compile, or (b) work... I don't have an alpha
to play with.
It looks ok at a first glance, I can try it today.
I also don't know the alpha function calling convention,
On Fri, May 04, 2001 at 01:15:28PM +0400, Ivan Kokshaysky wrote:
However, there are 3 reasons why I prefer 16-bit counters:
I assume you mean 32bit counter. (that gives max 2^16 sleepers)
a. max user processes ulimit is much lower than 64K anyway;
the 2^16 limit is not a per-user limit it is
On Fri, May 04, 2001 at 10:22:53AM +0100, David Howells wrote:
I don't know whether it will (a) compile, or (b) work... I don't have an alpha
to play with.
Neither (a) nor (b) ;-) Corrected asm-alpha/rwsem.h attached.
Also small fix for lib/rwsem.c -- RWSEM_WAITING_BIAS-RWSEM_ACTIVE_BIAS
On Fri, May 04, 2001 at 04:33:59PM +0200, Andrea Arcangeli wrote:
the 2^16 limit is not a per-user limit it is a global one so the max
user process ulimit is irrelevant.
Only the number of pid and the max number of tasks supported by the
architecture is a relevant limit for this.
Thanks
On Fri, May 04, 2001 at 09:02:33PM +0400, Ivan Kokshaysky wrote:
But I can't imagine how this feature could be useful in a real life :-)
It will be required by the time we can fork more than 2^16 tasks (which
I'm wondering if it could be just the case if you use CLONE_PID as
root, I didn't
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
- removed some mb's for non-SMP
This isn't correct. Either you need atomic updates or you don't.
If you don't, then you shouldn't be using ll/sc at all. If you do
(perhaps to coordinate with devices) then the barriers are
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
Initially I tried to use __builtin_expect in the rwsem.h, but found
that it doesn't help at all in the small inline functions - it works
as expected only in a reasonably large block of code.
Eh? Would you give me an example
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
> Initially I tried to use __builtin_expect in the rwsem.h, but found
> that it doesn't help at all in the small inline functions - it works
> as expected only in a reasonably large block of code. Converting these
> functions into
Initially I tried to use __builtin_expect in the rwsem.h, but found
that it doesn't help at all in the small inline functions - it works
as expected only in a reasonably large block of code. Converting these
functions into the macros won't help, as callers are inline
functions also.
On the other
Initially I tried to use __builtin_expect in the rwsem.h, but found
that it doesn't help at all in the small inline functions - it works
as expected only in a reasonably large block of code. Converting these
functions into the macros won't help, as callers are inline
functions also.
On the other
On Thu, May 03, 2001 at 07:47:47PM +0400, Ivan Kokshaysky wrote:
Initially I tried to use __builtin_expect in the rwsem.h, but found
that it doesn't help at all in the small inline functions - it works
as expected only in a reasonably large block of code. Converting these
functions into the
28 matches
Mail list logo
