On Tue, 2015-03-03 at 14:44 -0800, Andrew Morton wrote:
> On Tue, 3 Mar 2015 10:44:24 -0700 Toshi Kani <toshi.k...@hp.com> wrote:
:
> > +
> > +#ifdef CONFIG_HAVE_ARCH_HUGE_VMAP
> > +int pud_set_huge(pud_t *pud, phys_addr_t addr, pgprot_t prot)
> > +{
> > + u8 mtrr;
> > +
> > + /*
> > + * Do not use a huge page when the range is covered by non-WB type
> > + * of MTRRs.
> > + */
> > + mtrr = mtrr_type_lookup(addr, addr + PUD_SIZE);
> > + if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != 0xFF))
> > + return 0;
>
> It would be good to notify the operator in some way when this happens.
> Otherwise the kernel will run more slowly and there's no way of knowing
> why. I guess slap a pr_info() in there. Or maybe pr_warn()?
We only use 4KB mappings today, so this case will not make it run
slowly, i.e. it will be the same as today. Also, adding a message here
can generate a lot of messages when MTRRs cover a large area. So, I
think we are fine without a message.
>
> > + prot = pgprot_4k_2_large(prot);
> > +
> > + set_pte((pte_t *)pud, pfn_pte(
> > + (u64)addr >> PAGE_SHIFT,
> > + __pgprot(pgprot_val(prot) | _PAGE_PSE)));
> > +
> > + return 1;
> > +}
> > +
> > +int pmd_set_huge(pmd_t *pmd, phys_addr_t addr, pgprot_t prot)
> > +{
> > + u8 mtrr;
> > +
> > + /*
> > + * Do not use a huge page when the range is covered by non-WB type
> > + * of MTRRs.
> > + */
> > + mtrr = mtrr_type_lookup(addr, addr + PMD_SIZE);
> > + if ((mtrr != MTRR_TYPE_WRBACK) && (mtrr != 0xFF))
> > + return 0;
> > +
> > + prot = pgprot_4k_2_large(prot);
> > +
> > + set_pte((pte_t *)pmd, pfn_pte(
> > + (u64)addr >> PAGE_SHIFT,
> > + __pgprot(pgprot_val(prot) | _PAGE_PSE)));
> > +
> > + return 1;
> > +}
> >
> > +int pud_clear_huge(pud_t *pud)
> > +{
> > + if (pud_large(*pud)) {
> > + pud_clear(pud);
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
> > +
> > +int pmd_clear_huge(pmd_t *pmd)
> > +{
> > + if (pmd_large(*pmd)) {
> > + pmd_clear(pmd);
> > + return 1;
> > + }
> > +
> > + return 0;
> > +}
>
> I didn't see anywhere where the return values of these functions are
> documented. It's all fairly obvious, but we could help the rearers
> a bit.
Agreed. I will add function headers with descriptions to the new
functions.
Thanks,
-Toshi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
