* Jimi Xenidis <[EMAIL PROTECTED]> [2007-02-23 15:04]:
> On Feb 21, 2007, at 6:17 PM, Ryan Harper wrote:
>
> NOTE: Linux creates its own stack so there is we do not need the
> following:
> /* put stack below everything */
> v->arch.ctxt.gprs[1] = dst - STACK_FRAME_OVERHEAD;
>
Testing th
On Mon, 2007-02-19 at 17:03 +0900, Isaku Yamahata wrote:
> Attached the updated patches. Please find them
>
> - 13985_4fa9b86d41b8_grow_granttable_acm.patch
> acm part. I did only compile test.
>
> - 13986_cca098fd122c_grow_granttable_ia64.patch
> ia64 part.
>
> - 13987_f5f232aef7bd_
On 26/2/07 23:31, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
>
> Hi Yamahata-san, thanks very much for your patch!
>
> I'm confused about one thing though: why do we need to take a lock to
> read d->grant_table->nr_grant_frames? It's a simple integer, so no lock
> is required or useful.
I ha
On Mon, 2007-02-26 at 23:39 +, Keir Fraser wrote:
> On 26/2/07 23:31, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
>
> >
> > Hi Yamahata-san, thanks very much for your patch!
> >
> > I'm confused about one thing though: why do we need to take a lock to
> > read d->grant_table->nr_grant_fram
On 27/2/07 00:05, "Hollis Blanchard" <[EMAIL PROTECTED]> wrote:
> I don't believe that's a concern, since updating
> grant_table->nr_grant_frames is the very last step in
> gnttab_grow_table(), and it will only grow.
If there's a memory barrier before the update of nr_grant_frames, explicitly
