Derek Murray wrote:
> The 128-grant limit is fairly arbitrary, and I wanted to see how people
> were using gntdev before changing this. The reason for using a
> fixed-size array is that it gives us O(1)-time mapping and unmapping of
> single grants, which I anticipated would be the most frequently-used
> case.

Ok, try a hash instead of a list then ;)

>> Second problem is that batched grant mappings (using
>> xc_gnttab_map_grant_refs) don't work reliable.  Symtoms I see are random
>> failures with ENOMEM for no obvious reason (128 grant limit is *far*
>> away).
> 
> If it's failing with ENOMEM, a possible reason is that the address space
> for mapping grants within gntdev (the array I mentioned above) is
> becoming fragmented. Are you combining the mapping of single grants and
> batches within the same gntdev instance?

Yes, I'm mixing up single and batched maps (the later can have different
sizes too, depending on the requests coming in, in the 1 -> 11 range).
But I've seen ENOMEM failures with *only* the shared ring being mapped,
i.e. one of 128 slots being used.  That can't be fragmentation ...

>> Also host kernel crashes (kernel 2.6.21-2952.fc8xen).
> 
> When does this happen? Could you post the kernel OOPS?

Dunno what exactly triggers it.  Oops attached.

cheers,
  Gerd