| To: | Luben Tuikov <luben@xxxxxxxxxxxx> |
|---|---|
| Subject: | Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c |
| From: | Andi Kleen <ak@xxxxxxx> |
| Date: | Wed, 23 Oct 2002 06:18:50 +0200 |
| Cc: | Andi Kleen <ak@xxxxxxx>, Christoph Hellwig <hch@xxxxxxxxxxxxx>, linux-xfs <linux-xfs@xxxxxxxxxxx>, Eric Sandeen <sandeen@xxxxxxx> |
| In-reply-to: | <3DB62268.79A724BC@splentec.com> |
| References: | <3DB49424.9E4CAC0F@splentec.com> <20021022213140.A11191@infradead.org> <3DB5CC26.D5F4BB84@splentec.com> <20021023051713.B17128@wotan.suse.de> <3DB62268.79A724BC@splentec.com> |
| Sender: | linux-xfs-bounce@xxxxxxxxxxx |
| User-agent: | Mutt/1.3.22.1i |
> >From what I can see and read, wake_up() and wake_up_sync() both wake > up all non-exclusive sleepers and one exclusive sleeper. > > The NON _sync versions, OTOH, will call reschedule_idle(), which _may_ > cause (if the conditions are favourable) _another_ task to run > on _another_ CPU (SMP), _before_ the wake_up() returns. Yes of course. But other CPUs are completely independent anyways, so there can be tasks scheduled there any time, no matter if you call wake_up or not. > This will cause a problem if that other task does IO on xfs > and the code is as it was several days ago. Can you explain how exactly that leads to problems ? -Andi |
| Previous by Date: | Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c, Luben Tuikov |
|---|---|
| Next by Date: | TAKE - Revert STATIC->static change, Keith Owens |
| Previous by Thread: | Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c, Luben Tuikov |
| Next by Thread: | Re: PATCH: sleeping while holding a lock in _pagebuf_free_bh()::page_buf.c, Luben Tuikov |
| Indexes: | [Date] [Thread] [Top] [All Lists] |