Re: [RFCv3][PATCH 1/3] create slow_virt_to_phys()

[Dave Hansen]

On 01/15/2013 11:46 AM, H. Peter Anvin wrote:
> I object to this switch statement.  If we are going to create new
> primitives, let's create a primitive that embody this and put it in
> pgtypes_types.h, especially since it is simply an algorithmic operation:

Yeah, that's a good point.  I did at least copy part of the switch from
elsewhere in the file, so there's certainly room for consolidating some
things.

> static inline unsigned long page_level_size(int level)
> {
>     return (PAGE_SIZE/PGDIR_SIZE) << (PGDIR_SHIFT*level);
> }
> static inline unsigned long page_level_shift(int level)
> {
>     return (PAGE_SHIFT-PGDIR_SHIFT) + (PGDIR_SHIFT*level);
> }

(PAGE_SHIFT-PGDIR_SHIFT) == -27, so this can't possibly work, right?

How about something like this?

/*
 * Note: this only holds true for pagetable levels where PTEs can be
 * present.  It would break if you used it on the PGD level where PAE
 * is in use.  It basically assumes that the shift between _all_
 * adjacent levels of the pagetables are the same as the lowest-level
 * shift.
 */
#define PG_SHIFT_PER_LEVEL (PMD_SHIFT-PAGE_SHIFT)

static inline unsigned long page_level_shift(int level)
{
	return PAGE_SHIFT + (level - PG_LEVEL_4K) * PG_SHIFT_PER_LEVEL;
}
static inline unsigned long page_level_size(int level)
{
	return 1 << page_level_shift(level);
}

The generated code for page_level_size() looks pretty good, despite it
depending on page_level_shift(), so we might as well leave it defined
this way for simplicity:

0000000000400610 <plsize>:
  400610:       8d 7c bf fb             lea    -0x5(%rdi,%rdi,4),%edi
  400614:       b8 01 00 00 00          mov    $0x1,%eax
  400619:       8d 4c 3f 0c             lea    0xc(%rdi,%rdi,1),%ecx
  40061d:       d3 e0                   shl    %cl,%eax
  40061f:       c3                      retq

I'll send out another series doing this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/