Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*RT\s+and\s+XFS\s*$/>

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*RT\s+and\s+XFS\s*$/: 32 ]

Total 32 documents matching your query.

1. Re: RT and XFS (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Thu, 14 Jul 2005 10:22:46 +1000; Hi there, Hmm, I'm not aware of anywhere in XFS where we do that. From talking to some colleagues here, they're claiming that we can't be doing that since it'd trip an assert in the IRIX mrlock code.; /archives/xfs/2005-07/msg00079.html (10,869 bytes)
2. Re: RT and XFS (score: 1): Author: Dave Chinner <dgc@xxxxxxx>; Date: Thu, 14 Jul 2005 13:50:23 +1000; 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; /archives/xfs/2005-07/msg00082.html (11,623 bytes)
3. Re: RT and XFS (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Wed, 13 Jul 2005 21:10:26 -0700; Where is the that semaphore spec, is that posix ? There is a new construct called "complete" that is good for this type of stuff too. No owner needed , just something running, and something waiting t; /archives/xfs/2005-07/msg00083.html (10,740 bytes)
4. Re: RT and XFS (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Thu, 14 Jul 2005 07:23:48 +0200; wrt. posix, we dont really care about that for kernel-internal primitives like struct semaphore. So whether it's posix or not has no relevance. wrt. 'struct completion' - completions should indeed be; /archives/xfs/2005-07/msg00084.html (10,825 bytes)
5. Re: RT and XFS (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Thu, 14 Jul 2005 08:56:58 -0700; 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 (; /archives/xfs/2005-07/msg00092.html (10,836 bytes)
6. Re: RT and XFS (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 14 Jul 2005 17:08:38 +0100; --end quoted text--; /archives/xfs/2005-07/msg00093.html (12,731 bytes)
7. Re: RT and XFS (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Thu, 14 Jul 2005 17:08:35 +0100; Daniel, get a fucking clue. Read some CS 101 literature on what a semaphore is defined to be. If you want PI singing dancing blinking christmas tree locking primites call them a mutex, but not a sema; /archives/xfs/2005-07/msg00094.html (11,377 bytes)
8. Re: RT and XFS (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Fri, 15 Jul 2005 12:23:11 +0200; 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 and we dont care. PI can also be pretty expensiv; /archives/xfs/2005-07/msg00097.html (9,706 bytes)
9. Re: RT and XFS (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Fri, 15 Jul 2005 09:16:55 -0700; 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; /archives/xfs/2005-07/msg00100.html (10,059 bytes)
10. Re: RT and XFS (score: 1): Author: Esben Nielsen <simlo@xxxxxxxxxx>; Date: Mon, 18 Jul 2005 13:33:07 +0200 (METDST); Is PI needed? If you use a mutex to protect a critical area you are destroying the strict meaning of priorities if the mutex doesn't have PI: Priority inversion can effectively make the high priority; /archives/xfs/2005-07/msg00108.html (12,051 bytes)
11. Re: RT and XFS (score: 1): Author: Esben Nielsen <simlo@xxxxxxxxxx>; Date: Mon, 18 Jul 2005 14:10:31 +0200 (METDST); As a matter of fact I just finished what corresponds to your "CS 101" (I study CS in spare time while having a full time job coding RT stuff): To the one lecture I attended they talked about sempahor; /archives/xfs/2005-07/msg00109.html (11,130 bytes)
12. Re: RT and XFS (score: 1): Author: "Richard B. Johnson" <linux-os@xxxxxxxxxxxx>; Date: Mon, 18 Jul 2005 08:17:19 -0400 (EDT); On Mon, 18 Jul 2005, Esben Nielsen wrote: 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_nons; /archives/xfs/2005-07/msg00110.html (12,484 bytes)
13. Re: RT and XFS (score: 1): Author: Bill Huey (hui) <bhuey@xxxxxxxx>; Date: Mon, 18 Jul 2005 20:31:32 -0700; It depends on what kind of PI under specific circumstances. In the general kernel, it's really to be avoided at all costs since it's masking a general contention problem at those places. In a formall; /archives/xfs/2005-07/msg00116.html (10,167 bytes)
14. Re: RT and XFS (score: 1): Author: Bill Huey (hui) <bhuey@xxxxxxxx>; Date: Mon, 18 Jul 2005 20:26:24 -0700; This is where you failed. You assumed that that person making the comment, Christopher, in the first place didn't have his head up his ass in the first place and was open to your end of the discussio; /archives/xfs/2005-07/msg00117.html (9,521 bytes)
15. Re: RT and XFS (score: 1): Author: Christoph Hellwig <hch@xxxxxxxxxxxxx>; Date: Tue, 19 Jul 2005 14:27:50 +0100; Actually having a mutex_t in mainline would be a good idea even without preempt rt, to document better what kind of locking we expect.; /archives/xfs/2005-07/msg00118.html (10,721 bytes)
16. Re: RT and XFS (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Tue, 19 Jul 2005 15:50:56 +0200; cool! I'll cook up a patch for that. Right now these are the numbers: there are 526 uses of struct semaphore in 2.6.12. In the -RT tree i had to change 23 of them to be compat_semaphore - i.e. 23 use; /archives/xfs/2005-07/msg00119.html (10,731 bytes)
17. Re: RT and XFS (score: 1): Author: Nathan Scott <nathans@xxxxxxx>; Date: Thu, 14 Jul 2005 10:22:46 +1000; Hi there, Hmm, I'm not aware of anywhere in XFS where we do that. From talking to some colleagues here, they're claiming that we can't be doing that since it'd trip an assert in the IRIX mrlock code.; /archives/xfs/2005-07/msg00219.html (10,869 bytes)
18. Re: RT and XFS (score: 1): Author: Dave Chinner <dgc@xxxxxxx>; Date: Thu, 14 Jul 2005 13:50:23 +1000; 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; /archives/xfs/2005-07/msg00222.html (11,623 bytes)
19. Re: RT and XFS (score: 1): Author: Daniel Walker <dwalker@xxxxxxxxxx>; Date: Wed, 13 Jul 2005 21:10:26 -0700; Where is the that semaphore spec, is that posix ? There is a new construct called "complete" that is good for this type of stuff too. No owner needed , just something running, and something waiting t; /archives/xfs/2005-07/msg00223.html (10,740 bytes)
20. Re: RT and XFS (score: 1): Author: Ingo Molnar <mingo@xxxxxxx>; Date: Thu, 14 Jul 2005 07:23:48 +0200; wrt. posix, we dont really care about that for kernel-internal primitives like struct semaphore. So whether it's posix or not has no relevance. wrt. 'struct completion' - completions should indeed be; /archives/xfs/2005-07/msg00224.html (10,825 bytes)

Current List: 1 - 20
Page: [1] [2]