lkml.org 
[lkml]   [2000]   [Jan]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: (*(unsigned long *)&jiffies)++;
Petko Manolov wrote:
>
> Andrea Arcangeli wrote:
> >
> > On Fri, 7 Jan 2000, Petko Manolov wrote:
> >
> > >Lock don't hurt anyway.
> >
> > Locks definitely _hurt_ performance very badly. Locks don't scale in SMP
> > so if you lock the bus all the time only once CPU between the NR_CPUS will
> > run and the other will stall at the first memory bus access. Locks also
> > prevents the locking-CPU to reorder instructions on IA32. locks hurt also
> > in UP for this reason.
>
> Hm, bus locks are expensive. But AFAIK lock is done only over the
> accessed
> address not the whole memory. And this should be true for everything
> newer
> than 386. So is possible CPU1 to access one _real_ address and CPU2
> access
> other _real_ adress at the same time.
> But i'll not bet on this until i read the manuals ;-))

that's true, but don't forget there is only one bus (on
most PCs anyway). three cases to consider are:

1. the cpu has the cache line loaded in exclusive state -- free.
2. the cpu has the cache line loaded in shared state - requires a
bus transaction to get to exclusive state.
3. the cpu doesn't have the data in the cache -- requires a
load of the cache line.

case #3 is expensive and enough of #2 can still swamp the bus.
note that a lock pinging between two or more cpus amounts to
numerous cache transfers between the cpus which will slow down
other users of the bus.

jan-simon.

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

\
 
 \ /
  Last update: 2005-03-22 13:55    [W:0.080 / U:1.752 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site