On Wed, Nov 29, 2006 at 01:39:22AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 09:20:24 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > What I'm looking for is confirmation of the semantics of
> > find_next_zero_bit()
>
> What are the existing semantics? I see no documentation in any
On Wed, 29 Nov 2006 09:20:24 +
Russell King <[EMAIL PROTECTED]> wrote:
> What I'm looking for is confirmation of the semantics of
> find_next_zero_bit()
What are the existing semantics? I see no documentation in any of the
architectures I've looked at. That's my point.
>From a quick read o
On Wed, Nov 29, 2006 at 12:30:36AM -0800, Andrew Morton wrote:
> On Wed, 29 Nov 2006 07:40:00 +
> Russell King <[EMAIL PROTECTED]> wrote:
>
> > Yet another attempt to get a response from Andrew. It is rather
> > important that you DO respond to this.
>
> You can read the code as easily as I
On Wed, 29 Nov 2006 07:40:00 +
Russell King <[EMAIL PROTECTED]> wrote:
> Yet another attempt to get a response from Andrew. It is rather
> important that you DO respond to this.
You can read the code as easily as I can? I'm not really sure what
you're asking - I thought Mingming cleared thi
Yet another attempt to get a response from Andrew. It is rather
important that you DO respond to this.
On Sat, Nov 25, 2006 at 02:59:16PM +, Russell King wrote:
> On Thu, Nov 16, 2006 at 12:34:48PM +, Russell King wrote:
> > On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
>
On Tue, 2006-11-28 at 14:33 -0800, Andrew Morton wrote:
> On Tue, 28 Nov 2006 13:04:53 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Thanks, I have acked most of them, and will port them to ext3/4 soon.
>
> You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
> uncle
On Tue, 28 Nov 2006 13:04:53 -0800
Mingming Cao <[EMAIL PROTECTED]> wrote:
> Thanks, I have acked most of them, and will port them to ext3/4 soon.
You've acked #2 and #3. #4, #5 and #6 remain un-commented-upon and #1 is
unclear?
-
To unsubscribe from this list: send the line "unsubscribe linux-k
On Tue, 2006-11-28 at 17:38 +, Hugh Dickins wrote:
> >
> > And could you check the start and end block for every rsv_window_add and
> > rsv_window_remove, to see if it was keep creating and removing the same
> > window in the same block group?
>
> The same every time it settled on a usable re
On Tue, 21 Nov 2006, Mingming Cao wrote:
> On Mon, 2006-11-20 at 16:19 +, Hugh Dickins wrote:
> > After four days of running, the EM64T has at last reproduced the same
> > hang as it did in an hour before: stuck in
> > ext2_try_to_allocate_with_rsv,
> > repeatedly ext2_rsv_window_add, ext2_try_
On Thu, 16 Nov 2006 12:15:16 -0800
Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> > On Thu, 16 Nov 2006 00:49:20 -0800
> > Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > > On Wed,
On Thu, 2006-11-16 at 01:13 -0800, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > > On Wed, 15 Nov 2006 22:55:43 -0800
> > > Mingming Cao <[EMAIL PROTECTED]> wrote:
> > >
> > > >
On Thu, 16 Nov 2006, Andrew Morton wrote:
> On Thu, 16 Nov 2006 00:49:20 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > That does not explain the repeated reservation window add and remove
> > behavior Huge has reported.
>
> I spent quite some time comparing with ext3. I'm a bit stumped
On Wed, Nov 15, 2006 at 11:22:28PM -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
>
On Thu, 16 Nov 2006 12:37:17 +0300
Alex Tomas <[EMAIL PROTECTED]> wrote:
> > Andrew Morton (AM) writes:
>
> AM> What lock protects the fields in struct ext[234]_reserve_window from
> being
> AM> concurrently modified by two CPUs? None, it seems. Ditto
> AM> ext[234]_reserve_window_node.
On Thu, 16 Nov 2006 01:48:09 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Thu, 16 Nov 2006 12:37:17 +0300
> Alex Tomas <[EMAIL PROTECTED]> wrote:
>
> > > Andrew Morton (AM) writes:
> >
> > AM> What lock protects the fields in struct ext[234]_reserve_window from
> > being
> > AM> co
> Andrew Morton (AM) writes:
AM> What lock protects the fields in struct ext[234]_reserve_window from being
AM> concurrently modified by two CPUs? None, it seems. Ditto
AM> ext[234]_reserve_window_node. i_mutex will cover it for write(), but not
AM> for pageout over a file hole. If we
On Thu, 16 Nov 2006 00:49:20 -0800
Mingming Cao <[EMAIL PROTECTED]> wrote:
> On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> > On Wed, 15 Nov 2006 22:55:43 -0800
> > Mingming Cao <[EMAIL PROTECTED]> wrote:
> >
> > > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
On Tue, 2006-11-14 at 11:31 -0800, Andrew Morton wrote:
> On Tue, 14 Nov 2006 19:11:22 + (GMT)
> Hugh Dickins <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 14 Nov 2006, Mel Gorman wrote:
> > > 2.6.19-rc5-mm2
> > >
> > > Am seeing errors with systems using ext2. First machine is a plan old x86
> >
On Wed, 2006-11-15 at 23:22 -0800, Andrew Morton wrote:
> On Wed, 15 Nov 2006 22:55:43 -0800
> Mingming Cao <[EMAIL PROTECTED]> wrote:
>
> > Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> > number of the range to search, not the lengh of the range. maxblocks
> > get p
On Wed, 15 Nov 2006 22:55:43 -0800
Mingming Cao <[EMAIL PROTECTED]> wrote:
> Hmm, maxblocks, in bitmap_search_next_usable_block(), is the end block
> number of the range to search, not the lengh of the range. maxblocks
> get passed to ext2_find_next_zero_bit(), where it expecting to take the
Andrew Morton wrote:
On Wed, 15 Nov 2006 14:17:01 + (GMT)
Hugh Dickins <[EMAIL PROTECTED]> wrote:
On Tue, 14 Nov 2006, Hugh Dickins wrote:
On Tue, 14 Nov 2006, Andrew Morton wrote:
The below might help.
Indeed it does (with Martin's E2FSBLK warning fix),
seems to be running well on a
21 matches
Mail list logo
