On Sat, Feb 03, 2007 at 10:24:04PM -0500, Alan Stern wrote:
> On Sat, 3 Feb 2007, Paul E. McKenney wrote:
>
> > > And another note: this all assumes that STORE-MB-LOAD works "correctly",
> > > yes?
> > > We have other code which relies on that, should not be a problem.
> >
> > We have been worki
On Sat, 3 Feb 2007, Paul E. McKenney wrote:
> > And another note: this all assumes that STORE-MB-LOAD works "correctly",
> > yes?
> > We have other code which relies on that, should not be a problem.
>
> We have been working with Doug Lea of SUNY Oswego, Sebatian Burckhardt of
> University of Pe
On Sat, Feb 03, 2007 at 07:38:50PM +0300, Oleg Nesterov wrote:
> On 01/31, Paul E. McKenney wrote:
> >
> > QRCU as currently written (http://lkml.org/lkml/2006/11/29/330) doesn't
> > do what you want, as it acquires the lock unconditionally. I am proposing
> > that synchronize_qrcu() change to som
On 01/31, Paul E. McKenney wrote:
>
> QRCU as currently written (http://lkml.org/lkml/2006/11/29/330) doesn't
> do what you want, as it acquires the lock unconditionally. I am proposing
> that synchronize_qrcu() change to something like the following:
>
> void synchronize_qrcu(struct qrcu_s
On Fri, Feb 02, 2007 at 02:56:12PM +0300, Oleg Nesterov wrote:
> On 02/01, Paul E. McKenney wrote:
> > > >
> > > > void synchronize_qrcu(struct qrcu_struct *qp)
> > > > {
> > > > int idx;
> > > >
> > > > smp_mb();
> > > >
> > > >
On Fri, 2007-02-02 at 14:56 +0300, Oleg Nesterov wrote:
> On 02/01, Paul E. McKenney wrote:
> > > >
> > > > void synchronize_qrcu(struct qrcu_struct *qp)
> > > > {
> > > > int idx;
> > > >
> > > > smp_mb();
> > > >
> > > >
On 02/01, Paul E. McKenney wrote:
> > >
> > > void synchronize_qrcu(struct qrcu_struct *qp)
> > > {
> > > int idx;
> > >
> > > smp_mb();
> > >
> > > if (atomic_read(qp->ctr[0]) + atomic_read(qp->ctr[1]) <= 1) {
> > > smp_rmb();
> > >
On Thu, Feb 01, 2007 at 07:00:10PM +0300, Oleg Nesterov wrote:
> On 01/31, Paul E. McKenney wrote:
> >
> > QRCU as currently written (http://lkml.org/lkml/2006/11/29/330) doesn't
> > do what you want, as it acquires the lock unconditionally. I am proposing
> > that synchronize_qrcu() change to so
On 01/31, Paul E. McKenney wrote:
>
> QRCU as currently written (http://lkml.org/lkml/2006/11/29/330) doesn't
> do what you want, as it acquires the lock unconditionally. I am proposing
> that synchronize_qrcu() change to something like the following:
>
> void synchronize_qrcu(struct qrcu_
On Thu, Feb 01, 2007 at 01:03:09AM +0100, Peter Zijlstra wrote:
> On Wed, 2007-01-31 at 15:32 -0800, Paul E. McKenney wrote:
>
> > The wakeup in barrier_sync() would mean that the counter was zero
> > at some point in the past. The counter would then be rechecked, and
> > if it were still zero, b
On Wed, 2007-01-31 at 15:32 -0800, Paul E. McKenney wrote:
> The wakeup in barrier_sync() would mean that the counter was zero
> at some point in the past. The counter would then be rechecked, and
> if it were still zero, barrier_sync() would invoke finish_wait() and
> then return -- but the coun
On Wed, Jan 31, 2007 at 10:48:21PM +0100, Peter Zijlstra wrote:
> On Thu, 2007-02-01 at 00:13 +0300, Oleg Nesterov wrote:
> > On 01/31, Paul E. McKenney wrote:
> > > On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
> > > > * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > > > > On Sun,
On Thu, 2007-02-01 at 00:13 +0300, Oleg Nesterov wrote:
> On 01/31, Paul E. McKenney wrote:
> >
> > On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
> > >
> > > * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> > >
> > > > On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
On 02/01, Oleg Nesterov wrote:
>
> +static inline void barrier_sync(struct barrier *b)
> +{
> + might_sleep();
> +
> + if (unlikely(atomic_read(&b->count))) {
> + DEFINE_WAIT(wait);
> + prepare_to_wait(&b->wait, &wait, TASK_UNINTERRUPTIBLE);
> +
On 01/31, Paul E. McKenney wrote:
>
> On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
> >
> > * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> >
> > > On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> > > > This barrier thing is constructed so that it will not write i
On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
>
> * Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> > On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> > > This barrier thing is constructed so that it will not write in the
> > > sync() condition (the hot path) whe
On Sun, Jan 28, 2007 at 04:24:35PM +0100, Ingo Molnar wrote:
> > > This barrier thing is constructed so that it will not write in the
> > > sync() condition (the hot path) when there are no active lock
> > > sections; thus avoiding cacheline bouncing. -- I'm just not sure how
> > > this will wor
* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> > This barrier thing is constructed so that it will not write in the
> > sync() condition (the hot path) when there are no active lock
> > sections; thus avoiding cacheline bouncin
On Sun, Jan 28, 2007 at 12:51:21PM +0100, Peter Zijlstra wrote:
> This barrier thing is constructed so that it will not write in the sync()
> condition (the hot path) when there are no active lock sections; thus avoiding
> cacheline bouncing. -- I'm just not sure how this will work out in relation
19 matches
Mail list logo
