mmap_write_trylock() and vma_try_start_write() were added just for
khugepaged, but now it has no use for them: delete.
Signed-off-by: Hugh Dickins
---
include/linux/mm.h| 17 -
include/linux/mmap_lock.h | 10 --
2 files changed, 27 deletions(-)
diff --git a/inclu
Now that retract_page_tables() can retract page tables reliably, without
depending on trylocks, delete all the apparatus for khugepaged to try
again later: khugepaged_collapse_pte_mapped_thps() etc; and free up the
per-mm memory which was set aside for that in the khugepaged_mm_slot.
But one part
Bring collapse_and_free_pmd() back into collapse_pte_mapped_thp().
It does need mmap_read_lock(), but it does not need mmap_write_lock(),
nor vma_start_write() nor i_mmap lock nor anon_vma lock. All racing
paths are relying on pte_offset_map_lock() and pmd_lock(), so use those.
Follow the pattern
Simplify shmem and file THP collapse's retract_page_tables(), and relax
its locking: to improve its success rate and to lessen impact on others.
Instead of its MADV_COLLAPSE case doing set_huge_pmd() at target_addr of
target_mm, leave that part of the work to madvise_collapse() calling
collapse_pt
Add the generic pte_free_defer(), to call pte_free() via call_rcu().
pte_free_defer() will be called inside khugepaged's retract_page_tables()
loop, where allocating extra memory cannot be relied upon. This version
suits all those architectures which use an unfragmented page for one page
table (no
Add s390-specific pte_free_defer(), to call pte_free() via call_rcu().
pte_free_defer() will be called inside khugepaged's retract_page_tables()
loop, where allocating extra memory cannot be relied upon. This precedes
the generic version to avoid build breakage from incompatible pgtable_t.
This v
Add sparc-specific pte_free_defer(), to call pte_free() via call_rcu().
pte_free_defer() will be called inside khugepaged's retract_page_tables()
loop, where allocating extra memory cannot be relied upon. This precedes
the generic version to avoid build breakage from incompatible pgtable_t.
Signe
Add powerpc-specific pte_free_defer(), to call pte_free() via call_rcu().
pte_free_defer() will be called inside khugepaged's retract_page_tables()
loop, where allocating extra memory cannot be relied upon. This precedes
the generic version to avoid build breakage from incompatible pgtable_t.
Sig
Instead of pte_lockptr(), use the recently added pte_offset_map_nolock()
in assert_pte_locked(). BUG if pte_offset_map_nolock() fails: this is
stricter than the previous implementation, which skipped when pmd_none()
(with a comment on khugepaged collapse transitions): but wouldn't we want
to know,
Instead of pte_lockptr(), use the recently added pte_offset_map_nolock()
in adjust_pte(): because it gives the not-locked ptl for precisely that
pte, which the caller can then safely lock; whereas pte_lockptr() is not
so tightly coupled, because it dereferences the pmd pointer again.
Signed-off-by
There is a faint risk that __pte_offset_map(), on a 32-bit architecture
with a 64-bit pmd_t e.g. x86-32 with CONFIG_X86_PAE=y, would succeed on
a pmdval assembled from a pmd_low and a pmd_high which never belonged
together: their combination not pointing to a page table at all, perhaps
not even a v
Before putting them to use (several commits later), add rcu_read_lock()
to pte_offset_map(), and rcu_read_unlock() to pte_unmap(). Make this a
separate commit, since it risks exposing imbalances: prior commits have
fixed all the known imbalances, but we may find some have been missed.
Signed-off-
Here is the third series of patches to mm (and a few architectures), based
on v6.4-rc3 with the preceding two series applied: in which khugepaged
takes advantage of pte_offset_map[_lock]() allowing for pmd transitions.
This follows on from the "arch: allow pte_offset_map[_lock]() to fail"
https://
kallsyms_lookup which in turn calls for kallsyms_lookup_buildid()
writes on index "KSYM_NAME_LEN - 1".
Thus array size should be KSYM_NAME_LEN.
for powerpc and hexagon it was defined as "128" directly.
and commit '61968dbc2d5d' changed define value to 512,
So both were missed to update with new s
On Tue, May 23, 2023 at 08:26:32AM +0200, Joerg Roedel wrote:
> On Tue, May 16, 2023 at 09:35:25PM -0300, Jason Gunthorpe wrote:
> > With POWER SPAPR now having a real iommu driver and using the normal group
> > lifecycle stuff fixing FSL will leave only VFIO's no-iommu support as a
> > user for th
On Sun, May 28, 2023 at 12:37:17PM +0100, Greg Kroah-Hartman wrote:
> On Thu, May 18, 2023 at 01:01:02AM +0200, Uwe Kleine-König wrote:
> > Hello,
> >
> > this series convers the drivers below drivers/usb to the .remove_new()
> > callback of struct platform_driver(). The motivation is to make the
On Thu, May 18, 2023 at 01:01:02AM +0200, Uwe Kleine-König wrote:
> Hello,
>
> this series convers the drivers below drivers/usb to the .remove_new()
> callback of struct platform_driver(). The motivation is to make the
> remove callback less prone for errors and wrong assumptions. See commit
> 5c
> Why is this driver caring if debugfs is working or not at all? It
> should just ignore the error and keep moving forward.
I do not know. But, if the authors of the driver have decided to check for
the error, maybe use the more appropriate way?
Thanks.
Immad.
On Sun, May 28, 2023 at 1:27 PM Gr
On Sun, May 28, 2023 at 01:16:44PM +0530, mirim...@outlook.com wrote:
> From: Immad Mir
>
> The debugfs_create_dir returns ERR_PTR incase of an error and the
> correct way of checking it by using the IS_ERR inline function, and
> not the simple null comparision. This patch fixes this.
>
> Sugges
From: Immad Mir
The debugfs_create_dir returns ERR_PTR incase of an error and the
correct way of checking it by using the IS_ERR inline function, and
not the simple null comparision. This patch fixes this.
Suggested-By: Ivan Orlov
Signed-off-by: Immad Mir
---
arch/powerpc/platforms/powernv/op
20 matches
Mail list logo
