Skip to content
  1. Jun 30, 2008
  3. Jun 27, 2008
  5. Jun 26, 2008
  7. Jun 20, 2008
    • Linus Torvalds's avatar
      Reinstate ZERO_PAGE optimization in 'get_user_pages()' and fix XIP · 89f5b7da
      Linus Torvalds authored 
      

KAMEZAWA Hiroyuki and Oleg Nesterov point out that since the commit
557ed1fa ("remove ZERO_PAGE") removed
the ZERO_PAGE from the VM mappings, any users of get_user_pages() will
generally now populate the VM with real empty pages needlessly.

We used to get the ZERO_PAGE when we did the "handle_mm_fault()", but
since fault handling no longer uses ZERO_PAGE for new anonymous pages,
we now need to handle that special case in follow_page() instead.

In particular, the removal of ZERO_PAGE effectively removed the core
file writing optimization where we would skip writing pages that had not
been populated at all, and increased memory pressure a lot by allocating
all those useless newly zeroed pages.

This reinstates the optimization by making the unmapped PTE case the
same as for a non-existent page table, which already did this correctly.

While at it, this also fixes the XIP case for follow_page(), where the
caller could not differentiate between the case of a page that simply
could not be used (because it had no "struct page" associated with it)
and a page that just wasn't mapped.

We do that by simply returning an error pointer for pages that could not
be turned into a "struct page *".  The error is arbitrarily picked to be
EFAULT, since that was what get_user_pages() already used for the
equivalent IO-mapped page case.

[ Also removed an impossible test for pte_offset_map_lock() failing:
  that's not how that function works ]

Acked-by: default avatarOleg Nesterov <oleg@tv-sign.ru>
Acked-by: default avatarNick Piggin <npiggin@suse.de>
Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Cc: Hugh Dickins <hugh@veritas.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Roland McGrath <roland@redhat.com>
Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      89f5b7da
  9. Jun 18, 2008
    • Kumar Gala's avatar
      powerpc/booke: Add support for new e500mc core · 3dfa8773
      Kumar Gala authored 
      

The new e500mc core from Freescale is based on the e500v2 but with the
following changes:

* Supports only the Enhanced Debug Architecture (DSRR0/1, etc)
* Floating Point
* No SPE
* Supports lwsync
* Doorbell Exceptions
* Hypervisor
* Cache line size is now 64-bytes (e500v1/v2 have a 32-byte cache line)

Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
      3dfa8773
    • Paul Mackerras's avatar
      [POWERPC] Clear sub-page HPTE present bits when demoting page size · 65ba6cdc
      Paul Mackerras authored 
      

When we demote a slice from 64k to 4k, and we are about to insert an
HPTE for a 4k subpage and we notice that there is an existing 64k
HPTE, we first invalidate that HPTE before inserting the new 4k
subpage HPTE.  Since the bits that encode which hash bucket the old
HPTE was in overlap with the bits that encode which of the 16 subpages
have HPTEs, we need to clear out the subpage HPTE-present bits before
starting to insert HPTEs for the 4k subpages.  If we don't do that, we
can erroneously think that a subpage already has an HPTE when it
doesn't.

That in itself wouldn't be such a problem except that when we go to
update the HPTE that we think is present on machines with a
hypervisor, the hypervisor can tell us that the HPTE we think is there
is actually there even though it isn't, which can lead to a process
getting stuck in a loop, continually faulting.  The reason for the
confusion is that the AVPN (abbreviated virtual page number) we are
looking for in the HPTE for a 4k subpage can actually match the AVPN
in a stale HPTE for another 64k page.  For example, the HPTE for
the 4k subpage at 0x84000f000 will be in the same hash bucket and have
the same AVPN as the HPTE for the 64k page at 0x8400f0000.

This fixes the code to clear out the subpage HPTE-present bits.

Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      65ba6cdc
    • Josh Boyer's avatar
      [POWERPC] 4xx: Clear new TLB cache attribute bits in Data Storage vector · b17879f7
      Josh Boyer authored 
      

A recent commit added support for the new 440x6 and 464 cores that have the
added WL1, IL1I, IL1D, IL2I, and ILD2 bits for the caching attributes in the
TLBs.  The new bits were cleared in the finish_tlb_load function, however a
similar bit of code was missed in the DataStorage interrupt vector.

Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
Signed-off-by: default avatarPaul Mackerras <paulus@samba.org>
      b17879f7
  11. Jun 17, 2008
    • Josh Boyer's avatar
      powerpc/4xx: Workaround for PPC440EPx/GRx PCI_28 Errata · 5ce4b596
      Josh Boyer authored 
      

The 440EPx/GRx chips don't support PCI MRM commands.  Drivers determine this
by looking for a zero value in the PCI cache line size register.  However,
some drivers write to this register upon initialization.  This can cause
MRMs to be used on these chips, which may cause deadlocks on PLB4.

The workaround implemented here introduces a new indirect_type flag, called
PPC_INDIRECT_TYPE_BROKEN_MRM.  This is set in the pci_controller structure in
the pci fixup function for 4xx PCI bridges by determining if the bridge is
compatible with 440EPx/GRx.  The flag is checked in the indirect_write_config
function, and forces any writes to the PCI_CACHE_LINE_SIZE register to be
zero, which will disable MRMs for these chips.

A similar workaround has been tested by AMCC on various PCI cards, such as
the Silicon Image ATA card and Intel E1000 GIGE card.  Hangs were seen with
the Silicon Image card, and MRMs were seen on the bus with a PCI analyzer.
With the workaround in place, the card functioned properly and only Memory
Reads were seen on the bus with the analyzer.

Acked-by: default avatarStefan Roese <sr@denx.de>
Signed-off-by: default avatarJosh Boyer <jwboyer@linux.vnet.ibm.com>
      5ce4b596
  13. Jun 16, 2008
  15. Jun 11, 2008
  17. Jun 10, 2008