On Mon, 2005-04-18 at 19:00 +0100, Stephen C. Tweedie wrote:
> > > Note that there _is_ some additional complexity here. It's not entirely
> > > free. Specifically, if we have other tasks waiting on our provisional
> > > window, then we need to be very careful about the life expectancy of the
>
Hi,
On Fri, 2005-04-15 at 21:32, Mingming Cao wrote:
> Sorry for the delaying. I was not in office these days.
No problem.
> > > Also I am concerned about the possible
> > > starvation on writers.
> > In what way?
> I was worried about the rw lock case.:)
OK, so we're both on the same track he
Hi,
On Wed, 2005-04-13 at 00:27, Mingming Cao wrote:
> > I wonder if there's not a simple solution for this --- mark the window
> > as "provisional", and if any other task tries to allocate in the space
> > immediately following such a window, it needs to block until that window
> > is released.
On Tue, 2005-04-12 at 12:18 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Tue, 2005-04-12 at 07:41, Mingming Cao wrote:
>
> > > Note that this may improve average case latencies, but it's not likely
> > > to improve worst-case ones. We still need a write lock to install a new
> > > window, and t
Hi,
On Tue, 2005-04-12 at 07:41, Mingming Cao wrote:
> > Note that this may improve average case latencies, but it's not likely
> > to improve worst-case ones. We still need a write lock to install a new
> > window, and that's going to have to wait for us to finish finding a free
> > bit even if
On Mon, 2005-04-11 at 20:57 +0100, Stephen C. Tweedie wrote:
> Hi,
Hi Stephen,
>
> On Mon, 2005-04-11 at 19:38, Mingming Cao wrote:
> > Ah.. I see the win with the read lock now: once the a reservation window
> > is added, updating it (either winding it forward and or searching for a
> > avalia
Hi,
On Mon, 2005-04-11 at 19:38, Mingming Cao wrote:
> I agree. We should not skip the home block group of the file. I guess
> what I was suggesting is, if allocation from the home group failed and
> we continuing the linear search the rest of block groups, we could
> probably try to skip the bl
On Mon, 2005-04-11 at 15:12 -0400, Lee Revell wrote:
> On Mon, 2005-04-11 at 11:38 -0700, Mingming Cao wrote:
> > I will work on a patch for Lee to try sometime tonight.
> >
>
> Just FYI, this will take a while to test, because this latency seems
> quite rare. I haven't seen it again since my or
On Mon, 2005-04-11 at 11:38 -0700, Mingming Cao wrote:
> I will work on a patch for Lee to try sometime tonight.
>
Just FYI, this will take a while to test, because this latency seems
quite rare. I haven't seen it again since my original report.
Hopefully I can reproduce it with enough dbench pr
On Mon, 2005-04-11 at 12:48 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:
>
> > > It still needs to be done under locking to prevent us from expanding
> > > over the next window, though. And having to take and drop a spinlock a
> > > dozen times or m
Hi,
On Fri, 2005-04-08 at 19:10, Mingming Cao wrote:
> > It still needs to be done under locking to prevent us from expanding
> > over the next window, though. And having to take and drop a spinlock a
> > dozen times or more just to find out that there are no usable free
> > blocks in the curren
On Fri, 2005-04-08 at 11:10 -0700, Mingming Cao wrote:
> However I am still worried that the rw lock will allow concurrent files
> trying to lock the same window at the same time. Only one succeed
> though., high cpu usage then. And also, in the normal case the
> filesystem is not really full, pro
On Fri, 2005-04-08 at 15:40 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Fri, 2005-04-08 at 00:37, Mingming Cao wrote:
>
> > Actually, we do not have to do an rbtree link and unlink for every
> > window we search. If the reserved window(old) has no free bit and the
> > new reservable window's i
> And rw locking is much better for concurrency, so
> we might be able to hold it over the whole bitmap search rather than
> taking it and dropping it at each window advance.
rw locks only help if readers are 10x more common than writers generally
speaking. They are quite expensive locks, so they
Hi,
On Fri, 2005-04-08 at 00:37, Mingming Cao wrote:
> Actually, we do not have to do an rbtree link and unlink for every
> window we search. If the reserved window(old) has no free bit and the
> new reservable window's is right after the old one, no need to unlink
> the old window from the rbtr
On Thu, 2005-04-07 at 14:08 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
>
> > doesnt the first option also allow searches to be in parallel?
>
> In terms of CPU usage, yes. But either we use large windows, in which
> case we *can't* search remotely
On Thu, 2005-04-07 at 14:08 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
>
> > doesnt the first option also allow searches to be in parallel?
>
> In terms of CPU usage, yes. But either we use large windows, in which
> case we *can't* search remotely
Hi,
On Thu, 2005-04-07 at 09:14, Ingo Molnar wrote:
> doesnt the first option also allow searches to be in parallel?
In terms of CPU usage, yes. But either we use large windows, in which
case we *can't* search remotely near areas of the disk in parallel; or
we use small windows, in which case f
* Mingming Cao <[EMAIL PROTECTED]> wrote:
> It seems we are holding the rsv_block while searching the bitmap for a
> free bit. In alloc_new_reservation(), we first find a available to
> create a reservation window, then we check the bitmap to see if it
> contains any free block. If not, we wi
On Wed, 2005-04-06 at 19:22 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, 2005-04-06 at 17:53, Mingming Cao wrote:
>
> > > Possible, but not necessarily nice. If you've got a nearly-full disk,
> > > most bits will be already allocated. As you scan the bitmaps, it may
> > > take quite a whi
Hi,
On Wed, 2005-04-06 at 17:53, Mingming Cao wrote:
> > Possible, but not necessarily nice. If you've got a nearly-full disk,
> > most bits will be already allocated. As you scan the bitmaps, it may
> > take quite a while to find a free bit; do you really want to (a) lock
> > the whole block g
On Wed, 2005-04-06 at 10:51 +0100, Stephen C. Tweedie wrote:
> Hi,
>
> On Wed, 2005-04-06 at 06:35, Mingming Cao wrote:
>
> > It seems we are holding the rsv_block while searching the bitmap for a
> > free bit.
>
> Probably something to avoid!
>
> > In alloc_new_reservation(), we first find a
Hi,
On Wed, 2005-04-06 at 06:35, Mingming Cao wrote:
> It seems we are holding the rsv_block while searching the bitmap for a
> free bit.
Probably something to avoid!
> In alloc_new_reservation(), we first find a available to
> create a reservation window, then we check the bitmap to see if i
On Tue, 2005-04-05 at 06:13 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > I can trigger latencies up to ~1.1 ms with a CVS checkout. It looks
> > like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
> > loop:
> >
> > ext3_test_allocatable (bitmap_se
On Mon, 2005-04-04 at 23:10 -0700, Mingming Cao wrote:
> On Tue, 2005-04-05 at 06:13 +0200, Ingo Molnar wrote:
> > * Lee Revell <[EMAIL PROTECTED]> wrote:
> >
> > > I can trigger latencies up to ~1.1 ms with a CVS checkout. It looks
> > > like inside ext3_try_to_allocate_with_rsv, we spend a long
On Tue, 2005-04-05 at 06:13 +0200, Ingo Molnar wrote:
> * Lee Revell <[EMAIL PROTECTED]> wrote:
>
> > I can trigger latencies up to ~1.1 ms with a CVS checkout. It looks
> > like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
> > loop:
> >
We have not modify the reservation
* Lee Revell <[EMAIL PROTECTED]> wrote:
> I can trigger latencies up to ~1.1 ms with a CVS checkout. It looks
> like inside ext3_try_to_allocate_with_rsv, we spend a long time in this
> loop:
>
> ext3_test_allocatable (bitmap_search_next_usable_block)
> find_next_zero_bit (bitmap_search_next_us
27 matches
Mail list logo
