gntshr stubs unnecessarily inefficient

[djs55]

The stub does this:

CAMLprim value
stub_gntshr_grant_access(value v_ref, value v_iopage, value v_domid, value v_wri
table)
{
    grant_ref_t ref = Int_val(v_ref);
    void *page = base_page_of(v_iopage);
    gntshr_grant_access(ref, page, Int_val(v_domid), !Bool_val(v_writable));

    return Val_unit;
}

where base_page_of looks up the data pointer of the Caml_ba_array_val. This means that to share a contiguous batch of pages we need to use Io_page.get_n (allocating a large page-aligned bigarray) and then use Io_page.to_pages to chop the buffer into separate pages, via Bigarray.Array1.sub.

It would be better to call Io_page.(to_cstruct (get_n ...)) and then to chop the Cstruct into pages since Cstruct.sub is cheaper than Bigarray.Array1.sub. We would modify the stub to take a Cstruct and compute the real page pointer by adding the buffer.Cstruct.off field.

Our code is using a mixture of Io_page.t and Cstruct.t which is a bit confusing. I think we sometimes use Io_page.t to guarantee alignment but this means we end up doing Bigarray.Array1.sub more often than we should and, if we don't do that and use Cstruct.sub instead, we have hard-to-find bugs where the wrong page is granted because of base_page_of.

[samoht]

Is this what is causing the weird 4ms wait doing lots Gntshr.grant in http://openmirage.org/wiki/profiling graphs?

[djs55]

Dunno... 4ms is quite a lot!
On 14 Dec 2014 22:56, "Thomas Gazagnaire" notifications@github.com wrote:

Is this what is causing the weird 4ms wait doing lots Gntshr.grant in
http://openmirage.org/wiki/profiling graphs?

—
Reply to this email directly or view it on GitHub
#110 (comment)
.

[hannesm]

copied as mirage/mirage-xen#2 - the new home of mirage-xen