From: Mandeep Singh Baines <msb@google.com>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, rientjes@google.com,
mbligh@google.com, thockin@google.com
Subject: Re: [PATCH v3] softlockup: remove hung_task_check_count
Date: Fri, 23 Jan 2009 17:55:14 -0800 [thread overview]
Message-ID: <20090124015513.GA31189@google.com> (raw)
In-Reply-To: <c62985530901230204i3880c3f8xbebdb6844f35addf@mail.gmail.com>
Frédéric Weisbecker (fweisbec@gmail.com) wrote:
> 2009/1/23 Ingo Molnar <mingo@elte.hu>:
> >
> > not sure i like the whole idea of removing the max iterations check. In
> > theory if there's a _ton_ of tasks, we could spend a lot of time looping
> > there. So it always looked prudent to limit it somewhat.
> >
>
> Which means we can loose several of them. Would it hurt to iterate as
> much as possible along the task list,
> keeping some care about writers starvation and latency?
> BTW I thought about the slow work framework, but I can't retrieve
> it.... But this thread has already a slow priority.
>
> Would it be interesting to provide a way for rwlocks to know if there
> is writer waiting for the lock?
Would be cool if that API existed. You could release the CPU and/or lock as
soon as either was contended for. You'd have the benefits of fine-grained
locking without the overhead of locking and unlocking multiple time.
Currently, there is no bit that can tell you there is a writer waiting. You'd
probably need to change the write_lock() implementation at a minimum. Maybe
if the first writer left the RW_LOCK_BIAS bit clear and then waited for the
readers to leave instead of re-trying? That would actually make write_lock()
more efficient for the 1-writer case since you'd only need to spin doing
a read in the failure case instead of an atomic_dec and atomic_inc.
next prev parent reply other threads:[~2009-01-24 1:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-21 1:46 [PATCH] softlockup: remove hung_task_check_count Mandeep Singh Baines
2009-01-21 11:13 ` Ingo Molnar
2009-01-21 13:14 ` Frédéric Weisbecker
2009-01-22 0:54 ` [PATCH v2] " Mandeep Singh Baines
2009-01-22 8:34 ` Ingo Molnar
2009-01-22 19:55 ` [PATCH v3] " Mandeep Singh Baines
2009-01-23 3:21 ` Mandeep Baines
2009-01-23 9:23 ` Ingo Molnar
2009-01-23 10:04 ` Frédéric Weisbecker
2009-01-24 1:55 ` Mandeep Singh Baines [this message]
2009-01-24 15:52 ` Frederic Weisbecker
2009-01-26 2:25 ` Mandeep Baines
2009-01-24 2:56 ` Mandeep Singh Baines
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090124015513.GA31189@google.com \
--to=msb@google.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbligh@google.com \
--cc=mingo@elte.hu \
--cc=rientjes@google.com \
--cc=thockin@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.