t there that would
be exposed to this, when it only require a small patch to avoid it.
On the other hand, it's also reasonable to claim that this is part of the
evolving HMM feature, and as such, this new feature does not belong in
stable. I'm not sure which argument carries more weight here.
thanks,
--
John Hubbard
NVIDIA
>
> Cheers,
> Jérôme
>
eaders.
>
> That doesn't seem to warrant a -stable backport? The developer of such
> a driver will simply fix the headers?
Right. For this patch, I would strongly request a -stable backport. It's
really going to cause problems if anyone tries to use -stable with HMM,
without
@vger.kernel.org
> Cc: Evgeny Baskakov
> Cc: Ralph Campbell
> Cc: Mark Hairgrove
> Cc: John Hubbard
> ---
> mm/hmm.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/mm/hmm.c b/mm/hmm.c
> index 6088fa6ed137..64d9e7dae712 100644
> --- a/mm/h
mirror_register(), to handle that. Especially
considering
that right now, hmm_mirror_register() will return success in this case--so
there is no indication that anything is wrong.
Maybe hmm_mirror_register() could return an error (and not add to the mirror
list),
in such a situation, how's that sound?
thanks,
--
John Hubbard
NVIDIA
On 03/16/2018 12:14 PM, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
Hi Jerome,
I failed to find any problems in this patch, so:
Reviewed-by: John Hubbard
There are a couple of documentation recommended typo fixes listed
below, which are very minor but as long as I'm here
change
> or any other operations that allow you to get the memory value through
> them.
>
> Signed-off-by: Jérôme Glisse
> Cc: Evgeny Baskakov
> Cc: Ralph Campbell
> Cc: Mark Hairgrove
> Cc: John Hubbard
> ---
> include/linux/hmm.h |
On 03/16/2018 07:36 PM, John Hubbard wrote:
> On 03/16/2018 12:14 PM, jgli...@redhat.com wrote:
>> From: Ralph Campbell
>>
>
>
>
>> +static void hmm_release(struct mmu_notifier *mn, struct mm_struct *mm)
>> +{
>> +struct hmm *hmm = mm->hmm;
>
On 03/16/2018 12:14 PM, jgli...@redhat.com wrote:
> From: Jérôme Glisse
>
Hi Jerome,
This one looks great. A couple of trivial typo fixes are listed below.
You can add:
Reviewed-by: John Hubbard
> All device driver we care about are using 64bits page table entry. In
> order t
unsigned long addr, i = 0;
for (addr = range->start; addr < range->end; addr += PAGE_SIZE, i++)
range->pfns[i] = HMM_PFN_SPECIAL;
Either way,
Reviewed-by: John Hubbard
thanks,
--
John Hubbard
NVIDIA
On 03/16/2018 08:47 PM, John Hubbard wrote:
> On 03/16/2018 07:36 PM, John Hubbard wrote:
>> On 03/16/2018 12:14 PM, jgli...@redhat.com wrote:
>>> From: Ralph Campbell
>>>
>>
>>
>>
>>> +static void hmm_release(struct mmu_notifier *mn, str
hat hard to hit it: just a good directed stress
test involving multiple threads that are doing early process termination
while also doing lots of migrations and page faults, should suffice.
It is probably best to add this patch to stable, for that reason.
thanks,
--
John Hubbard
NVIDIA
new routines (hmm_vma_handle_pte, and others)
That way, reviewers can see more easily that things are correct.
> Signed-off-by: Jérôme Glisse
> Cc: Evgeny Baskakov
> Cc: Ralph Campbell
> Cc: Mark Hairgrove
> Cc: John Hubbard
> ---
> include/linux/hmm
On 01/16/2017 11:51 PM, Michal Hocko wrote:
On Mon 16-01-17 13:57:43, John Hubbard wrote:
On 01/16/2017 01:48 PM, Michal Hocko wrote:
On Mon 16-01-17 13:15:08, John Hubbard wrote:
On 01/16/2017 11:40 AM, Michal Hocko wrote:
On Mon 16-01-17 11:09:37, John Hubbard wrote:
On 01/16/2017
On 01/18/2017 12:21 AM, Michal Hocko wrote:
On Tue 17-01-17 21:59:13, John Hubbard wrote:
On 01/16/2017 11:51 PM, Michal Hocko wrote:
On Mon 16-01-17 13:57:43, John Hubbard wrote:
On 01/16/2017 01:48 PM, Michal Hocko wrote:
On Mon 16-01-17 13:15:08, John Hubbard wrote:
On 01/16/2017
On 01/19/2017 12:45 AM, Michal Hocko wrote:
On Thu 19-01-17 00:37:08, John Hubbard wrote:
On 01/18/2017 12:21 AM, Michal Hocko wrote:
On Tue 17-01-17 21:59:13, John Hubbard wrote:
[...]
* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in
On 01/12/2017 07:37 AM, Michal Hocko wrote:
From: Michal Hocko
Using kmalloc with the vmalloc fallback for larger allocations is a
common pattern in the kernel code. Yet we do not have any common helper
for that and so users have invented their own helpers. Some of them are
really creative wh
On 01/16/2017 12:47 AM, Michal Hocko wrote:
On Sun 15-01-17 20:34:13, John Hubbard wrote:
On 01/12/2017 07:37 AM, Michal Hocko wrote:
[...]
diff --git a/mm/util.c b/mm/util.c
index 3cb2164f4099..7e0c240b5760 100644
--- a/mm/util.c
+++ b/mm/util.c
@@ -324,6 +324,48 @@ unsigned long vm_mmap
On 01/16/2017 11:40 AM, Michal Hocko wrote:
On Mon 16-01-17 11:09:37, John Hubbard wrote:
On 01/16/2017 12:47 AM, Michal Hocko wrote:
On Sun 15-01-17 20:34:13, John Hubbard wrote:
[...]
Is that "Reclaim modifiers" line still true, or is it a leftover from an
earlier approach? I
On 01/16/2017 01:48 PM, Michal Hocko wrote:
On Mon 16-01-17 13:15:08, John Hubbard wrote:
On 01/16/2017 11:40 AM, Michal Hocko wrote:
On Mon 16-01-17 11:09:37, John Hubbard wrote:
On 01/16/2017 12:47 AM, Michal Hocko wrote:
On Sun 15-01-17 20:34:13, John Hubbard wrote:
[...]
Is that
On 01/30/2017 05:57 PM, Dave Hansen wrote:
On 01/30/2017 05:36 PM, Anshuman Khandual wrote:
Let's say we had a CDM node with 100x more RAM than the rest of the
system and it was just as fast as the rest of the RAM. Would we still
want it isolated like this? Or would we want a different policy?
On 01/19/2017 01:56 AM, Michal Hocko wrote:
On Thu 19-01-17 01:09:35, John Hubbard wrote:
[...]
So that leaves us with maybe this for documentation?
* Reclaim modifiers - __GFP_NORETRY and __GFP_NOFAIL should not be passed in.
* Passing in __GFP_REPEAT is supported, and will cause the
fer way to
achieve the mapping.
Therefore, stop EXPORT-ing ioremap_page_range.
---
I may get some heat for this if another out-of-tree driver needs that symbol, but if no one else
pops up and shrieks, you can add:
Reviewed-by: John Hubbard
thanks,
john h
Signed-off-by: zhong jiang
On 01/22/2017 05:14 PM, zhong jiang wrote:
On 2017/1/22 20:58, zhongjiang wrote:
From: zhong jiang
Recently, I find the ioremap_page_range had been abusing. The improper
address mapping is a issue. it will result in the crash. so, remove
the symbol. It can be replaced by the ioremap_cache or
On 01/27/2017 02:52 PM, Jérôme Glisse wrote:
Cliff note: HMM offers 2 things (each standing on its own). First
it allows to use device memory transparently inside any process
without any modifications to process program code. Second it allows
to mirror process address space on a device.
Change s
-GPU cases, are all working.
We do think we've found a bug in a corner case that involves invalid GPU
memory (of course, it's always possible that the bug is on our side),
which Jerome is investigating now. If you spot the bug by inspection,
you'll get some major told-you-so points. :)
rrent draft, so brace yourself before saying yes... :)
thanks
John Hubbard
NVIDIA
Signed-off-by: Jérôme Glisse
---
Documentation/vm/hmm.txt | 362 +++
1 file changed, 362 insertions(+)
create mode 100644 Documentation/vm/hmm.txt
diff --git a/D
On 03/23/2017 07:41 PM, Huang, Ying wrote:
David Rientjes writes:
On Mon, 20 Mar 2017, Huang, Ying wrote:
From: Huang Ying
Now vzalloc() is used in swap code to allocate various data
structures, such as swap cache, swap slots cache, cluster info, etc.
Because the size may be too large on s
On 03/23/2017 09:52 PM, Huang, Ying wrote:
John Hubbard writes:
On 03/23/2017 07:41 PM, Huang, Ying wrote:
David Rientjes writes:
On Mon, 20 Mar 2017, Huang, Ying wrote:
From: Huang Ying
Now vzalloc() is used in swap code to allocate various data
structures, such as swap cache, swap
[...]
Hi Ying,
I'm a little surprised to see vmalloc calls replaced with
kmalloc-then-vmalloc calls, because that actually makes fragmentation
worse (contrary to the above claim). That's because you will consume
contiguous memory (even though you don't need it to be contiguous),
whereas before,
On 03/24/2017 09:52 AM, Tim Chen wrote:
On Fri, 2017-03-24 at 06:56 -0700, Dave Hansen wrote:
On 03/24/2017 12:33 AM, John Hubbard wrote:
There might be some additional information you are using to come up with
that conclusion, that is not obvious to me. Any thoughts there? These
calls use
On 03/14/2017 06:33 AM, Anshuman Khandual wrote:
On 03/08/2017 04:37 PM, John Hubbard wrote:
[...]
There was a discussion, on an earlier version of this patchset, in which
someone pointed out that a slight over-allocation on a device that has
much more memory than the CPU has, could use up
32-bit pfn.
So, given the current HMM design, I think we are going to have to provide a 32-bit version of these
routines (migrate_pfn_to_page, and related) that is a no-op, right?
thanks
John Hubbard
NVIDIA
On 03/16/2017 05:45 PM, Balbir Singh wrote:
On Fri, Mar 17, 2017 at 11:22 AM, John Hubbard wrote:
On 03/16/2017 04:05 PM, Andrew Morton wrote:
On Thu, 16 Mar 2017 12:05:26 -0400 Jérôme Glisse
wrote:
+static inline struct page *migrate_pfn_to_page(unsigned long mpfn)
+{
+ if (!(mpfn
the
MIGRATE_PFN_* defines? The 1ULL is what determines the type of the resulting number,
so it's one more tiny piece of type correctness that is good to have.
The rest of this fix looks good, and the above is not technically necessary (the
code that uses it will force its own type anyway),
*/
if (page_mapped(page)) {
- switch (ret = try_to_unmap(page,
- ttu_flags | TTU_BATCH_FLUSH)) {
- case SWAP_FAIL:
Again: the SWAP_FAIL makes it crystal clear which case we're in.
I also wonder if UNMAP_FAIL or TTU_RESULT_FAIL is a better name?
thanks,
John Hubbard
NVIDIA
t got interrupted, maybe?
The code changes look perfect, though. And although I'm not a fs guy, it seems
pretty clear that with all the callers passing in 1 all this time, nobody is likely
to complain about this simplification.
thanks,
John Hubbard
NVIDIA
No existing caller uses this on normal
From: John Hubbard
Hi,
Say, I'm 99% sure that this was just an oversight, so
I'm sticking my neck out here and floating a patch to
Put Things Back. I'm hoping that there is not some
firm reason to GPL-protect the basic kref_get and
kref_put routines, because when designing some
r
From: John Hubbard
Originally, kref_get and kref_put were available as
standard routines that even non-GPL device drivers
could use. However, as an unintended side effect of
the recent kref_*() upgrade[1], these calls are now
effectively GPL, because they get routed to the
new refcount_inc() and
On 03/08/2017 01:50 AM, Greg Kroah-Hartman wrote:
On Wed, Mar 08, 2017 at 01:25:49AM -0800, john.hubb...@gmail.com wrote:
From: John Hubbard
Originally, kref_get and kref_put were available as
standard routines that even non-GPL device drivers
could use.
As I stated in my response to the
lly, concisely addressed each one, somewhere, (maybe in a cover letter).
Because otherwise, it's too easy for earlier, important problems to be forgotten.
And reviewers don't want to have to repeat themselves, of course.
thanks
John Hubbard
NVIDIA
* CDM node's zones are part of
On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
On Wed, Mar 08, 2017 at 01:25:48AM -0800, john.hubb...@gmail.com wrote:
From: John Hubbard
Hi,
Say, I'm 99% sure that this was just an oversight, so
I'm sticking my neck out here and floating a patch to
Put Things Back. I
On 03/08/2017 02:12 AM, Greg Kroah-Hartman wrote:
On Wed, Mar 08, 2017 at 01:59:33AM -0800, John Hubbard wrote:
On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:
On Wed, Mar 08, 2017 at 01:25:48AM -0800, john.hubb...@gmail.com wrote:
From: John Hubbard
Hi,
Say, I'm 99% sure that thi
need to set an error in the
mapping when this fails, so I just added this to make it clear for any
new callers in the future.
Yes, somehow, even in this tiny patchset, I missed those two new comment lines.
arghh. :)
Well, everything looks great, then.
thanks,
John Hubbard
NVIDIA
On 03/08/2017 10:37 PM, Minchan Kim wrote:
>[...]
I think it's the matter of taste.
if (try_to_unmap(xxx))
something
else
something
It's perfectly understandable to me. IOW, if try_to_unmap returns true,
it means it did unmap successfully. Otherw
,
I'll get them to report back as well. I think John Hubbard has been
testing iterations as well. CC'ing other interested people as well
Balbir
Yes, Evgeny Baskakov and I have been testing each of the posted versions. We are using both
migration and mirroring, and have a small set of
o again: yes, both systems are providing a sort of coherent memory. HMM provides software based
coherence, while NUMA assumes hardware-based memory coherence as a prerequisite.
I hope that helps, and doesn't just further muddy the waters?
--
John Hubbard
NVIDIA
Thanks,
-Bob
Hi Anshuman,
I'd question the need to avoid kernel allocations in device memory.
Maybe we should simply allow these pages to *potentially* participate in
everything that N_MEMORY pages do: huge pages, kernel allocations, for
example.
No, allowing kernel allocations on CDM has two problems.
On 02/10/2017 02:06 AM, Anshuman Khandual wrote:
There are certain devices like specialized accelerator, GPU cards, network
cards, FPGA cards etc which might contain onboard memory which is coherent
along with the existing system RAM while being accessed either from the CPU
or from the device. Th
that.
thanks,
John Hubbard
NVIDIA
On 2020-05-26 11:27, John Hubbard wrote:
This code was using get_user_pages*(), in a "Case 1" scenario
(Direct IO), using the categorization from [1]. That means that it's
time to convert the get_user_pages*() + put_page() calls to
pin_user_
s used in most other call
sites.
Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC")
Cc: Derek Kiernan
Cc: Dragan Cvetic
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Michal Simek
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: John Hubbard
---
dr
. Any run-time
testing would be greatly appreciated!
Cc: Derek Kiernan
Cc: Dragan Cvetic
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Michal Simek
Cc: linux-arm-ker...@lists.infradead.org
John Hubbard (3):
misc: xilinx-sdfec: improve get_user_pages_fast() error handling
misc: xilinx-sdfec
radead.org
Signed-off-by: John Hubbard
---
drivers/misc/xilinx_sdfec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/drivers/misc/xilinx_sdfec.c
index e2766aad9e14..7e2ee3e547f2 100644
--- a/drivers/misc/xilinx_sdfec.c
+++ b/drivers/misc/xili
Kiernan
Cc: Dragan Cvetic
Cc: Arnd Bergmann
Cc: Greg Kroah-Hartman
Cc: Michal Simek
Cc: linux-arm-ker...@lists.infradead.org
Signed-off-by: John Hubbard
---
drivers/misc/xilinx_sdfec.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/misc/xilinx_sdfec.c b/dri
On 2020-05-27 01:51, Daniel Vetter wrote:
On Wed, May 27, 2020 at 10:48:52AM +0200, Daniel Vetter wrote:
On Tue, May 26, 2020 at 03:57:45PM -0700, John Hubbard wrote:
On 2020-05-26 14:00, Souptick Joarder wrote:
This code was using get_user_pages(), in a "Case 2" scenario
(DMA/RD
: linux-...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Signed-off-by: John Hubbard
---
Documentation/core-api/pin_user_pages.rst | 33 +--
1 file changed, 19 insertions(+), 14 deletions(-)
diff --git a/Documentation/core-api/pin_user_pages.rst
b/Documentation/core-api
is some helpful background in [2]: basically, this is a small
part of fixing a long-standing disconnect between pinning pages, and
file systems' use of those pages.
[1] Documentation/core-api/pin_user_pages.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Article
gup call sites
converted--with the notable exception of the bio/block layer.
[1] https://lore.kernel.org/r/20200518012157.1178336-2-jhubb...@nvidia.com
John Hubbard (2):
mm/gup: introduce pin_user_pages_locked()
mm/gup: frame_vector: convert get_user_pages() --> pin_user_pages()
incl
Introduce pin_user_pages_locked(), which is nearly identical to
get_user_pages_locked() except that it sets FOLL_PIN and rejects
FOLL_GET.
Signed-off-by: John Hubbard
---
include/linux/mm.h | 2 ++
mm/gup.c | 30 ++
2 files changed, 32 insertions(+)
diff
uld be more willing to pick them up.
Any testing help there is greatly appreciated!
thanks,
--
John Hubbard
NVIDIA
, though. And I *think* it's actually safe to
do this, as it stays away from writeback or other filesystem activity.
But let me double check that, in case I'm forgetting something.
thanks,
--
John Hubbard
NVIDIA
roblems that we saw. And
with this patch, we bail out of reclaim early.
[1] https://www.spinics.net/lists/linux-mm/msg142700.html
thanks,
--
John Hubbard
NVIDIA
.rst
[2] "Explicit pinning of user-space pages":
https://lwn.net/Articles/807108/
Signed-off-by: Souptick Joarder
Cc: John Hubbard
Cc: Boris Ostrovsky
Cc: Paul Durrant
---
Hi,
I'm compile tested this, but unable to run-time test, so any testing
help is much appricia
mson
Cc: Cornelia Huck
Cc: k...@vger.kernel.org
Signed-off-by: John Hubbard
---
Hi,
Changes since v1: rebased onto Linux-5.8-rc2.
thanks,
John Hubbard
drivers/vfio/vfio_iommu_spapr_tce.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drive
On 2020-06-25 22:26, Souptick Joarder wrote:
On Thu, Jun 25, 2020 at 11:19 AM John Hubbard wrote:
On 2020-06-24 20:02, Souptick Joarder wrote:
...
@@ -612,13 +612,7 @@ static int lock_pages(
static void unlock_pages(struct page *pages[], unsigned int nr_pages)
{
- unsigned int i
has not been required
so far, even though the call site conversions are nearly done.
thanks,
--
John Hubbard
NVIDIA
have?
No, they are not. And there are a couple more pre-existing cases as well,
right above what can be seen here (this patch just follows the local pattern)
that should also be removed.
thanks,
--
John Hubbard
NVIDIA
hew Wilcox
Cc: Zi Yan
Cc: John Hubbard
Cc: Naoya Horiguchi
Cc: Andrew Morton
Cc: linux...@kvack.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Zi Yan
Signed-off-by: Anshuman Khandual
This is missing the Documentation/ Cc's, did you run scripts/get_maintainer.pl?
I'm
On 2020-06-17 12:27, Souptick Joarder wrote:
Now there are 5 cases. Updated the same.
Signed-off-by: Souptick Joarder
Cc: John Hubbard
---
Documentation/core-api/pin_user_pages.rst | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/core-api/pin_user_pages.rst
faster.
unpin_user_pages()
is the right place to do so.
John any thought ?
So far I haven't seen any cases to justify changing the implementation of
unpin_user_pages().
thanks,
--
John Hubbard
NVIDIA
isabled: fallback to base page
OK, but *all* page entries (base and huge/large pages) need to be cleared,
when migrating to device memory, unless I'm really confused here.
So: not CoW.
thanks,
--
John Hubbard
NVIDIA
mmit
description, right? (It feels like a casualty of rearranging the patches.)
thanks,
--
John Hubbard
NVIDIA
27;s better for
maintenance, too, because the function never intends to migrate "some
number of bytes". It intends to migrate exactly one page.
Hope I'm not missing something fundamental, but:
Reviewed-by: John Hubbard
*,
u64 addr, u64 size);
Looks accurate: the order within vmm.c (now that there is no .h
declaration) is still good, and I found no other uses of either function
within the linux.git tree, so
Reviewed-by: John Hubbard
On 2020-06-12 12:24, Matthew Wilcox wrote:
On Fri, May 29, 2020 at 04:43:08PM -0700, John Hubbard wrote:
+CASE 5: Pinning in order to write to the data within the page
+-
+Even though neither DMA nor Direct IO is involved, just a
On 10/2/20 6:17 PM, John Hubbard wrote:
This patch reduces the running time for hmm-tests from about 10+
seconds, to just under 1.0 second, for an approximately 10x speedup.
That brings it in line with most of the other tests in selftests/vm,
which mostly run in < 1 sec.
This is done with a
the right thing, in other
words, after adding the new DUMP_USER_PAGES_TEST (a non-fast variant).
Reviewed-by: John Hubbard
[1] https://lore.kernel.org/r/20200929212747.251804-1-jhubb...@nvidia.com
thanks,
--
John Hubbard
NVIDIA
mm/gup_benchmark.c | 15 ---
1 file changed,
ddr PUD aligned */
+ MAKE_SIMPLE_TEST(PUD, PTE, _2GB),
+ MAKE_SIMPLE_TEST(PUD, _1MB, _2GB),
+ MAKE_SIMPLE_TEST(PUD, PMD, _2GB),
+ MAKE_SIMPLE_TEST(PUD, PUD, _2GB),
Too concise. Not fun lining these up with the stdout report.
thanks,
--
John Hubbard
NVIDIA
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency")
Signed-off-by: John Hubbard
---
Hi,
This applies to today's 20201001) linux-next. I forgot if this needs to
be a separate patch or if it can be fixed up in Andrew's tree.
thanks,
John Hubbard
On 10/1/20 11:48 PM, John Hubbard wrote:
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency") created the new check_config.sh file without the execute
bits set. This is a problem because the Makefile runs it with "./", so
now "make"
ts mostly take a few ms, and a few take 1.0 sec.
This drops the compaction_test run time from 27, to 3.3 sec. Enjoy. :)
thanks,
John Hubbard
NVIDIA
John Hubbard (1):
selftests/vm: 8x compaction_test speedup
tools/testing/selftests/vm/compaction_test.c | 11 ++-
1 file changed, 6 insert
.
Instead, do the mmaps 100 MB at a time. (Going past 100 MB doesn't make
things go much faster, because other parts of the program are using the
remaining time.)
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/compaction_test.c | 11 ++-
1 file changed, 6 insertions(
On 10/2/20 12:59 AM, Stephen Rothwell wrote:
Hi John,
On Thu, 1 Oct 2020 23:48:11 -0700 John Hubbard wrote:
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency") created the new check_config.sh file without the execute
bits set. This is a problem b
On 10/2/20 1:10 AM, John Hubbard wrote:
On 10/2/20 12:59 AM, Stephen Rothwell wrote:
Hi John,
On Thu, 1 Oct 2020 23:48:11 -0700 John Hubbard wrote:
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency") created the new check_config.sh file without t
executable bits.
Fixes: cb2ab76685d7 ("selftests/vm: rename run_vmtests --> run_vmtests.sh")
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/{run_vmtest.sh => run_vmtests.sh} | 0
1 file changed, 0 insertions(+), 0 deletions(-)
rename tools/testing/selftests/vm/{run_vm
commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency")
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/check_config.sh | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 tools/testing/selftests/vm/check_config.s
But I suspect these
patches will actually be merged back into Andrew's tree?)
thanks,
John Hubbard
NVIDIA
John Hubbard (2):
selftests/vm: fix: make check_config.sh executable
selftests/vm: fix run_vmtest.sh: restore executable bits, and "s" in
name
tools/t
On 10/2/20 2:59 PM, Andrew Morton wrote:
On Fri, 2 Oct 2020 01:40:49 -0700 John Hubbard wrote:
commit cb2ab76685d7 ("selftests/vm: rename run_vmtests -->
run_vmtests.sh") changed the name of run_vmtests to run_vmtest.sh, but
inadvertently dropped the executable bits.
We cannot
think it's really good that you've brought
this up. It's definitely time to add FOLL_LONGTERM wherever it's missing.
thanks,
--
John Hubbard
NVIDIA
There is already a dax specific check (added in b7f0554a56f2 ("mm:
fail get_vaddr_frames() for filesystem-dax mappings"
an nice touch, make check_config.sh executable as well.
Fixes: commit 30fb9454ab23 ("selftests/vm: hmm-tests: remove the libhugetlbfs
dependency")
Signed-off-by: John Hubbard
---
tools/testing/selftests/vm/Makefile| 2 +-
tools/testing/selftests/vm/check_config.sh | 0
2 files change
Here's v3, which treats the executable permissions of the two scripts here as
optional nice-to-have features.
It fixes the rename as well.
Again, I've put in commit hashes that are only valid in linux-next, so those
will need adjustment if these patches remain as distinct patches.
Jo
executable bit on that same file, as a
nice touch if it sticks. (Which it won't, if someone uses patch(1) to
apply this, but it's worth setting it for everyone else.)
Fixes: cb2ab76685d7 ("selftests/vm: rename run_vmtests --> run_vmtests.sh")
Signed-off-by: John Hubbard
---
too
the number of
iterations of several tests, from 256, to 10. Thanks to Ralph Campbell
for suggesting changing NTIMES as a way to get the speedup.
Suggested-by: Ralph Campbell
Signed-off-by: John Hubbard
---
This is based on mmotm.
tools/testing/selftests/vm/hmm-tests.c | 2 +-
1 file changed
On 10/2/20 10:23 PM, SeongJae Park wrote:
On Fri, 2 Oct 2020 18:17:21 -0700 John Hubbard wrote:
This patch reduces the running time for hmm-tests from about 10+
seconds, to just under 1.0 second, for an approximately 10x speedup.
That brings it in line with most of the other tests in
On 10/3/20 2:45 AM, Daniel Vetter wrote:
On Sat, Oct 3, 2020 at 12:39 AM John Hubbard wrote:
On 10/2/20 10:53 AM, Daniel Vetter wrote:
For $reasons I've stumbled over this code and I'm not sure the change
to the new gup functions in 55a650c35fea ("mm/gup: frame_vector:
convert
On 10/4/20 12:55 AM, Lukas Bulwahn wrote:
On Tue, 29 Sep 2020, John Hubbard wrote:
...
John, your change makes:
tools/testing/selftests$ make clean
fail with:
make[1]: Entering directory
'/home/lukas/repositories/kernel.org/pub/scm/linux/kernel/git/next/linux-next/tools/testing/selftes
IO_FOLL_PIN is not going to happen, but it's good to see
that the system isn't doing anything unexpected here.
thanks,
--
John Hubbard
NVIDIA
kern :warn : [ 59.774973] blk_update_request+0x219/0x3c0
kern :warn : [ 59.775767] scsi_end_request+0x29/0x140
kern :
: Kyungmin Park
Cc: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
patch 1: you can further simplify by using
unpin_user_pages_dirty_lock().
list_del(&userptr->job_node);
thanks,
--
John Hubbard
NVIDIA
: Kukjin Kim
Cc: Krzysztof Kozlowski
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
---
drivers/gpu/drm/exynos
On 10/7/20 9:44 AM, Daniel Vetter wrote:
These are persistent, not just for the duration of a dma operation.
Signed-off-by: Daniel Vetter
Cc: Jason Gunthorpe
Cc: Andrew Morton
Cc: John Hubbard
Cc: Jérôme Glisse
Cc: Jan Kara
Cc: Dan Williams
Cc: linux...@kvack.org
Cc: linux-arm-ker
601 - 700 of 1012 matches
Mail list logo
