* Christoph Hellwig <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 19, 2005 at 02:34:57PM +0200, Ingo Molnar wrote:
> > (I do disagree with Christoph on another point: i do think we eventually
> > want to change the standard semaphore type in a similar fashion upstream
> > as well - but that probably
On Tue, Jul 19, 2005 at 02:34:57PM +0200, Ingo Molnar wrote:
> (I do disagree with Christoph on another point: i do think we eventually
> want to change the standard semaphore type in a similar fashion upstream
> as well - but that probably has to come with a s/struct semaphore/struct
> mutex/ c
* Bill Huey <[EMAIL PROTECTED]> wrote:
> On Mon, Jul 18, 2005 at 02:10:31PM +0200, Esben Nielsen wrote:
> > Unfortunately, one of the goals of the preempt-rt branch is to avoid
> > altering too much code. Therefore the type semaphore can't be removed
> > there. Therefore the name still lingers ..
On Fri, Jul 15, 2005 at 09:16:55AM -0700, Daniel Walker wrote:
> I don't agree with that. But of course I'm always speaking from a real
> time perspective . PI is expensive , but it won't always be. However, no
> one is forcing PI on anyone, even if I think it's good ..
It depends on what kind of
On Mon, Jul 18, 2005 at 02:10:31PM +0200, Esben Nielsen wrote:
> Unfortunately, one of the goals of the preempt-rt branch is to avoid
> altering too much code. Therefore the type semaphore can't be removed
> there. Therefore the name still lingers ... :-(
This is where you failed. You assumed that
On Thu, 14 Jul 2005, Christoph Hellwig wrote:
> On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> > This reminds me of Documentation/stable_api_nonsense.txt . That no one
> > should really be dependent on a particular kernel API doing a particular
> > thing. The kernel is play dough
On Fri, 15 Jul 2005, Daniel Walker wrote:
> On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > PI is always good, cause it allows the tracking of what is high
> > > priority , and what is not .
> >
> > that's just plain wrong. PI might
On Fri, 2005-07-15 at 12:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > PI is always good, cause it allows the tracking of what is high
> > priority , and what is not .
>
> that's just plain wrong. PI might be good if one cares about priorities
> and worst-case
* Daniel Walker <[EMAIL PROTECTED]> wrote:
> PI is always good, cause it allows the tracking of what is high
> priority , and what is not .
that's just plain wrong. PI might be good if one cares about priorities
and worst-case latencies, but most of the time the kernel is plain good
enough an
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> >
> > > > The whole point of using a semaphore in the pagebuf is because there
> > > > is no tracking of who "owns" the lock so we
On Thu, Jul 14, 2005 at 08:56:58AM -0700, Daniel Walker wrote:
> This reminds me of Documentation/stable_api_nonsense.txt . That no one
> should really be dependent on a particular kernel API doing a particular
> thing. The kernel is play dough for the kernel hacker (as it should be),
> including k
On Thu, 2005-07-14 at 07:23 +0200, Ingo Molnar wrote:
> * Daniel Walker <[EMAIL PROTECTED]> wrote:
>
> > > The whole point of using a semaphore in the pagebuf is because there
> > > is no tracking of who "owns" the lock so we can actually release it
> > > in a different context. Semaphores were in
On Thu, 2005-07-14 at 13:50 +1000, Dave Chinner wrote:
> Now that I've read the thread, I see it's not mrlocks that is the
> issue with unlocking in a different context - it's semaphores.
>
> All the pagebuf synchronisation is done with a semaphore because
> it's held across the I/O and it's _most
On Thu, Jul 14, 2005 at 10:22:46AM +1000, Nathan Scott wrote:
> Hi there,
>
> On Wed, Jul 13, 2005 at 09:45:58AM -0700, Daniel Walker wrote:
> > On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
> > >
> > > downgrade_write() wasnt the main problem - the main problem was that for
> > > PREEMP
Hi there,
On Wed, Jul 13, 2005 at 09:45:58AM -0700, Daniel Walker wrote:
> On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
> >
> > downgrade_write() wasnt the main problem - the main problem was that for
> > PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
> > vani
On Wed, 2005-07-13 at 08:47 +0200, Ingo Molnar wrote:
>
> downgrade_write() wasnt the main problem - the main problem was that for
> PREEMPT_RT i implemented 'strict' semaphores, which are not identical to
> vanilla kernel semaphores. The thing that seemed to impact XFS the most
> is the 'acqui
* Nathan Scott <[EMAIL PROTECTED]> wrote:
> On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> >
> > Is there something so odd about the XFS locking, that it can't use the
> > rt_lock ?
>
> Not that I know of - XFS does use the downgrade_write interface, whose
> use isn't overly
On Tue, Jul 12, 2005 at 05:41:43PM -0700, Daniel Walker wrote:
> On Wed, 2005-07-13 at 10:25 +1000, Nathan Scott wrote:
> > On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> > >
> > > Is there something so odd about the XFS locking, that it can't use the
> > > rt_lock ?
> >
> > Not
On Wed, 2005-07-13 at 10:25 +1000, Nathan Scott wrote:
> On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
> >
> > Is there something so odd about the XFS locking, that it can't use the
> > rt_lock ?
>
> Not that I know of - XFS does use the downgrade_write interface,
> whose use isn
On Tue, Jul 12, 2005 at 04:01:32PM -0700, Daniel Walker wrote:
>
> Is there something so odd about the XFS locking, that it can't use the
> rt_lock ?
Not that I know of - XFS does use the downgrade_write interface,
whose use isn't overly common in the rest of the kernel... maybe
that has caused s
On Tue, 12 Jul 2005, Daniel Walker wrote:
> Is there something so odd about the XFS locking, that it can't use the
> rt_lock ?
>
>
> --- linux.orig/fs/xfs/linux-2.6/mrlock.h
> +++ linux/fs/xfs/linux-2.6/mrlock.h
> @@ -37,12 +37,12 @@
> enum { MR_NONE, MR_ACCESS, MR_UPDATE };
>
> typedef stru
21 matches
Mail list logo
