On Thu, Jan 16, 2025 at 12:02:34PM -0800, Paul E. McKenney wrote:
> +The special cases where it makes sense do obtain a per-CPU pointer in
s/do/to/
> +preemptible code are addressed by raw_cpu_ptr(), but please note that such
s/please note that //
> +use cases need to handle cases where two dif
On Mon, Jan 13, 2025 at 04:04:21PM +, Brendan Jackman wrote:
> Checkpatch sometimes has false positives. This makes it less useful for
> automatic usage: tools like b4 [0] can run checkpatch on all of your
> patches and give you a quick overview. When iterating on a branch, it's
> tiresome to m
On Thu, Dec 05, 2024 at 11:19:18AM -0800, Linus Torvalds wrote:
> Why do I care? Because long git commit IDs are actually detrimental to
> legibility. I try to make commit messages legible, and that very much
> is the *point* of the short format. It's for people, not machinery.
>
> Yes, the basic
On Mon, Dec 02, 2024 at 04:00:47PM +0100, Dragan Simic wrote:
> On 2024-11-09 04:10, Dragan Simic wrote:
> > On 2024-11-08 20:12, Dan Williams wrote:
> > > Dragan Simic wrote:
> > > > I'm fully aware that we may be reluctant to supporting
> > > > additional tags,
> > > > because we may then end up
On Tue, Nov 26, 2024 at 06:57:20PM -0800, Yuanchu Xie wrote:
> diff --git a/mm/internal.h b/mm/internal.h
> index 64c2eb0b160e..bbd3c1501bac 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -470,9 +470,14 @@ extern unsigned long highest_memmap_pfn;
> /*
> * in mm/vmscan.c:
> */
> +struc
On Tue, Nov 19, 2024 at 01:52:00PM +0100, Jann Horn wrote:
> > I will take reference, as we already do that for memcg purpose, but
> > have not included dump_page().
>
> Note that taking a reference on the page does not make all of
> dump_page() fine; in particular, my understanding is that
> foli
On Mon, Nov 18, 2024 at 03:40:57PM -0500, Pasha Tatashin wrote:
> > You're putting something in an mm/ C-file and the header in fs.h? Eh?
>
> This is done so we do not have to include struct path into vma.h. fs.h
> already has some vma functions like: vma_is_dax() and vma_is_fsdax().
Yes, but DAX
On Mon, Oct 14, 2024 at 05:03:32PM -0700, John Hubbard wrote:
> > > Or better yet, *always* fall back to page_ext, thus leaving the
> > > scarce and valuable page flags available for other features?
> > >
> > > Sorry Suren, to keep coming back to this suggestion, I know
> > > I'm driving you crazy
On Tue, Sep 10, 2024 at 04:57:41PM +1000, Alistair Popple wrote:
>
> Matthew Wilcox writes:
>
> > On Tue, Sep 10, 2024 at 02:14:29PM +1000, Alistair Popple wrote:
> >> @@ -337,6 +341,7 @@ struct folio {
> >>/* private: */
> >>
On Tue, Sep 10, 2024 at 02:14:29PM +1000, Alistair Popple wrote:
> @@ -337,6 +341,7 @@ struct folio {
> /* private: */
> };
> /* public: */
> + struct dev_pagemap *pgmap;
Shouldn't that be indented by one more tab stop?
And for ease of
On Wed, Sep 04, 2024 at 09:18:01AM -0700, Suren Baghdasaryan wrote:
> I'm not sure I understand your suggestion, Matthew. We allocate a
> folio and need to store a reference to the tag associated with the
> code that allocated that folio. We are not operating with ranges here.
> Are you suggesting
On Tue, Sep 03, 2024 at 06:25:52PM -0700, John Hubbard wrote:
> The more I read this story, the clearer it becomes that this should be
> entirely done by the build system: set it, or don't set it, automatically.
>
> And if you can make it not even a kconfig item at all, that's probably even
> bett
On Mon, Aug 19, 2024 at 01:39:16PM -0700, Suren Baghdasaryan wrote:
> On Mon, Aug 19, 2024 at 12:34 PM Matthew Wilcox wrote:
> > So if ALLOC_TAG_REF_WIDTH is big enough, it's going to force last_cpupid
> > into struct page.
>
> Thanks for taking a look!
> Yes, bu
On Mon, Aug 19, 2024 at 08:15:11AM -0700, Suren Baghdasaryan wrote:
> @@ -91,7 +97,7 @@
> #endif
>
> #if ZONES_WIDTH + LRU_GEN_WIDTH + SECTIONS_WIDTH + NODES_WIDTH + \
> - KASAN_TAG_WIDTH + LAST_CPUPID_SHIFT <= BITS_PER_LONG - NR_PAGEFLAGS
> + KASAN_TAG_WIDTH + ALLOC_TAG_REF_WIDTH + LAS
On Wed, May 22, 2024 at 04:46:27PM +0900, Sukrit Bhatnagar wrote:
> On the other hand, the struct slab has kmem_cache which maintains another set
> of flags. It would be nice to have these flags added as a part of the debug
> output, and to have a convenient way to print them.
I don't understand w
On Wed, May 22, 2024 at 04:46:29PM +0900, Sukrit Bhatnagar wrote:
> The function dump_page() prints "anon" even for slab pages.
> This is not correct, especially now that struct slab is separated from
> struct page, and that the slab pages cannot be mapped to userspace.
>
> [7.071985] page: re
On Tue, Apr 09, 2024 at 09:22:44PM +0200, David Hildenbrand wrote:
> Commit 53277bcf126d ("mm: support page_mapcount() on page_has_type()
> pages") made it impossible to detect mapcount underflows by treating
> any negative raw mapcount value as a mapcount of 0.
Yes, but I don't think this is the
On Fri, Feb 23, 2024 at 03:50:33PM -0800, Dan Williams wrote:
> Certainly something like that would have satisified this sanity test use
> case. I will note that mm_account_fault() would need some help to figure
> out the size of the page table entry that got installed. Maybe
> extensions to vm_fau
On Sat, Feb 03, 2024 at 10:53:45PM +0100, Thorsten Blum wrote:
> @@ -63,8 +63,7 @@ Image output
>
>
> The kernel documentation build system contains an extension that
> -handles images on both GraphViz and SVG formats (see
> -:ref:`sphinx_kfigure`).
> +handles images on both GraphV
On Thu, Jan 04, 2024 at 02:15:17PM -0500, Steven Rostedt wrote:
> On Thu, 4 Jan 2024 18:25:02 +
> Al Viro wrote:
>
> > Unfortunately, the terms are clumsy as hell - POSIX ends up with
> > "file descriptor" (for numbers) vs. "file description" (for IO
> > channels), which is hard to distinguis
On Thu, Jan 04, 2024 at 10:05:44AM -0500, Steven Rostedt wrote:
> > file_system_type: what filesystem instances belong to. Not quite the same
> > thing as fs driver (one driver can provide several of those). Usually
> > it's 1-to-1, but that's not required (e.g. NFS vs NFSv4, or ext[234],
> > or
On Sun, Dec 03, 2023 at 07:00:18PM +0530, attreyee-muk wrote:
> Hence, sending this patch. Requesting the maintains to have a look at
> it.
In addition to Greg's comment, after you have made changes to an rst
file, you have to try building the documents again (eg "make htmldocs").
I can see you'v
On Thu, Nov 30, 2023 at 06:58:16AM +0700, Bagas Sanjaya wrote:
> I do this posting because I thought the OP (Attreyee) didn't respond in
> timely manner (just like random Chinese contributors like @cdjrlc.com
> and @208suo.com people).
That's a ridiculous excuse. The original posting was two days
On Wed, Nov 29, 2023 at 07:29:35AM -0700, Jonathan Corbet wrote:
> Bagas Sanjaya writes:
>
> > I was prompted to write this little grammar fix series when reading
> > the fix from Attreyee [1], with review comments requesting changes
> > to that fix. So here's my version of the fix, with reviews
On Mon, Nov 27, 2023 at 11:41:31AM -0800, Randy Dunlap wrote:
> Hi,
>
> On 11/27/23 07:57, attreyee-muk wrote:
> > Respected Maintainers,
> >
> > I have made some grammatical changes in the livepatch.rst file where I
> > felt that the sentence would have sounded more correct and would have
> >
On Wed, Aug 25, 2021 at 08:10:39PM +0100, Joao Martins wrote:
> @@ -2273,8 +2273,7 @@ static int __gup_device_huge(unsigned long pfn,
> unsigned long addr,
> refs = record_subpages(page, addr, next, pages + *nr);
>
> SetPageReferenced(head);
> - pinne
On Sun, Oct 20, 2019 at 09:23:23PM +0800, Changbin Du wrote:
> The message "Function parameter or member ..." looks weird.
>
> Signed-off-by: Changbin Du
> ---
> scripts/kernel-doc | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/scripts/kernel-doc b/scripts/ker
On Mon, Oct 21, 2019 at 01:38:32PM +1300, Chris Packham wrote:
> "on the safe size" should be "on the safe side".
>
> Signed-off-by: Chris Packham
Yes, it should. Acked-by: Matthew Wilcox (Oracle)
If you like, you could do a follow-up patch mentioning the use
On Fri, Oct 04, 2019 at 10:39:54AM -0600, Jonathan Corbet wrote:
> To make the transition to the new model easier and prevent the breakage
> -of existing implementations, the :c:func:`__do_IRQ` super-handler is still
> +of existing implementations, the __do_IRQ() super-handler is still
> availabl
On Sat, Sep 07, 2019 at 11:17:22PM +0200, Thomas Gleixner wrote:
> On Sat, 7 Sep 2019, Markus Heiser wrote:
> > Am 07.09.19 um 20:04 schrieb Mauro Carvalho Chehab:
> > > No idea. I would actually prefer to just remove the restriction, and let
> > > the SPDX header to be anywhere inside the first co
On Mon, Sep 02, 2019 at 02:21:33PM -0600, Jonathan Corbet wrote:
> On Mon, 02 Sep 2019 21:19:24 +0200
> Federico Vaga wrote:
>
> > > > I am not used to the mathematical English jargon. It make sense, but
> > > > then
> > > > I
> > > > would replace it with "If and only if": for clarity.
> > >
On Thu, Aug 15, 2019 at 10:18:42AM -0400, Joel Fernandes (Google) wrote:
> list_for_each_entry_rcu now has support to check for RCU reader sections
> as well as lock. Just use the support in it, instead of explicitly
> checking in the caller.
...
> #define assert_rcu_or_wq_mutex_or_pool_mutex(wq
On Sun, Aug 04, 2019 at 04:46:35PM +0100, Sheriff Esseson wrote:
> Fix broken reference to virt/index.rst.
>
> Sequel to: 2f5947dfcaec ("Documentation: move Documentation/virtual to
> Documentation/virt")
'Sequel to'? Do you mean 'Fixes'?
> Reported-by: Sphinx
Reported-by is used for people.
On Tue, Jul 30, 2019 at 02:07:52PM -0700, Stephen Boyd wrote:
> The documentation for these functions indicates that callers don't need
> to hold a lock while calling them, but that documentation is only in one
> place under "IDA Usage". Let's state the same information on each IDA
> function so th
On Mon, Jul 22, 2019 at 10:58:15AM -0700, Joe Perches wrote:
> On Mon, 2019-07-22 at 10:43 -0700, Joe Perches wrote:
> > On Mon, 2019-07-22 at 10:33 -0700, Kees Cook wrote:
> > > On Thu, Jul 04, 2019 at 05:15:57PM -0700, Joe Perches wrote:
> > > > On Thu, 2019-07-04 at 13:46 -0700, Joe Perches wrot
On Sun, Jul 14, 2019 at 01:58:31PM +0100, Sheriff Esseson wrote:
> Move xfs.txt to admin-guide, convert xfs.txt to ReST and broken references
>
> Signed-off-by: Sheriff Esseson
Reviewed-by: Matthew Wilcox (Oracle)
On Tue, Jul 09, 2019 at 01:48:59PM +0100, Sheriff Esseson wrote:
> Convert xfs.txt to ReST, rename and fix broken references, consequently.
>
> Signed-off-by: Sheriff Esseson
> ---
>
> Changes in v6:
> - undo text reflow from v5.
> - fix a typo.
> - change indication of default
On Fri, Jul 05, 2019 at 08:41:48PM +0100, Sheriff Esseson wrote:
> On Fri, Jul 05, 2019 at 12:04:12PM -0700, Matthew Wilcox wrote:
> > On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> > > As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
On Sat, Jul 06, 2019 at 04:22:39PM -0700, Shobhit Kukreti wrote:
> +++ b/Documentation/filesystems/index.rst
> @@ -41,3 +41,4 @@ Documentation for individual filesystem types can be found
> here.
> :maxdepth: 2
>
> binderfs.rst
> + jfs
This is the wrong place for this file. See earli
On Fri, Jul 05, 2019 at 02:14:46PM +0100, Sheriff Esseson wrote:
> As suggested by Matthew Wilcox, xfs.txt is primarily a guide on available
> options when setting up an XFS. This makes it appropriate to be placed under
> the admin-guide tree.
>
> Thus, move xfs.txt to admin-guide
gt; You didn't add it to index.rst, so it won't actually become part of the
> docs build.
I think you added it in the wrong place.
>From 8167b80c950834da09a9204b6236f238197c197b Mon Sep 17 00:00:00 2001
From: "Matthew Wilcox (Oracle)"
Date: Tue, 2 Jul 2019 13:54:38 -0400
S
On Tue, Jul 02, 2019 at 01:30:40PM +0100, Sheriff Esseson wrote:
> +++ b/Documentation/filesystems/index.rst
> @@ -40,4 +40,5 @@ Documentation for individual filesystem types can be found
> here.
> .. toctree::
> :maxdepth: 2
>
> - binderfs.rst
> + binderfs
> + xfs
I don't think this
On Tue, Jul 02, 2019 at 01:30:40PM +0100, Sheriff Esseson wrote:
> +When mounting an XFS filesystem, the following options are accepted. For
> +boolean mount options, the names with the "(*)" prefix is the default
> behaviour.
> +For example, take a behaviour enabled by default to be a one (1) or
On Sat, Jun 29, 2019 at 02:25:08AM +0100, Sheriff Esseson wrote:
> On Fri, Jun 28, 2019 at 10:43:24PM +0100, Sheriff Esseson wrote:
> > Convert xfs.txt to ReST, markup and rename accordingly. Update
> > Documentation/index.rst.
Don't quote the entire previous patch when submitting a new on
On Fri, Jun 28, 2019 at 10:43:02PM +0100, Sheriff Esseson wrote:
> Convert xfs.txt to ReST, markup and rename accordingly. Update
> Documentation/index.rst.
Didn't get_maintainers.pl suggest that you cc the linux-xfs mailing list?
You also need to update MAINTAINERS.
> While at
On Tue, Mar 05, 2019 at 12:07:25PM -0800, Matthew Wilcox wrote:
> On Tue, Mar 05, 2019 at 11:59:30AM -0800, Joe Perches wrote:
> > Many of the -Wformat warnings are bogus too.
> >
> > There's nothing wrong with using %x for a unsigned int
> > of less than long size
On Tue, Mar 05, 2019 at 11:59:30AM -0800, Joe Perches wrote:
> Many of the -Wformat warnings are bogus too.
>
> There's nothing wrong with using %x for a unsigned int
> of less than long size. (u8/u16)
I believe you to be incorrect.
6.5.2.2 Function calls
7 If the expression that denotes the ca
On Tue, Mar 05, 2019 at 09:44:28AM +0800, Alex Shi wrote:
> >> Hi Alex,
> >>
> >> I will try to get the new email addresses for others too. Yes. But
> >> probably I will use a private email for this instead of the company email.
> > Here are the updated email address for me and others.
> >
> >
On Mon, Feb 18, 2019 at 04:34:26PM -0800, Randy Dunlap wrote:
> - * The `const' here prevents gcc-3.3 from calling __divdi3
> + * The ``const`` here prevents gcc-3.3 from calling __divdi3
Probably time to remove this hack ...
willy@bobo:~/kernel/idrext$ grep gcc Documentation/Changes
GNU C
On Thu, Feb 07, 2019 at 09:31:20AM -0800, Joe Perches wrote:
> It's not clear to me what you are asking checkpatch to do here.
>
> It may be reasonable for checkpatch to invoke kernel-doc on some
> portion of a patch, but I'm not sure how valuable it will be.
I was just hoping to match:
* Retur
This seems to be an extremely common mistake to make (indeed, almost
3000 occurrences of 'Returns:' vs 5300 occurrences of 'Return:'). Could
we have a checkpatch warning for it?
- Forwarded message from Matthew Wilcox -
On Wed, Jan 16, 2019 at 04:59:27PM +, Ch
On Fri, Feb 01, 2019 at 02:04:16PM -0800, frowand.l...@gmail.com wrote:
>Include documentation for each *function* in *source*.
> - If no *function* if specified, the documentaion for all functions
> + If no *function* if specified, the documentation for all functions
>and types in the *s
On Tue, Jan 15, 2019 at 12:26:31PM +0200, Joel Nider wrote:
> It is important to understand the existing framework when implementing
> a new verb. The majority of existing API functions are implemented using
> the write syscall, but this has been superceded by the ioctl syscall
> for new commands.
On Thu, Jan 10, 2019 at 11:48:13PM +, Jason Gunthorpe wrote:
> +The Linux kernel bool type is an alias for the C99 _Bool type. bool values
> can
> +only evaluate to 0 or 1, and implicit or explicit conversion to bool
> +automatically converts the value to true or false. When using bool types t
ped
> +on your distributions. In order to do so, it is recommended to install
s/on/with/
Other than that, Acked-by: Matthew Wilcox
On Sat, Jan 12, 2019 at 02:57:01PM +0800, Changbin Du wrote:
> This patch adds a new trace option 'funcgraph-retval' and is disabled by
> default. When this option is enabled, fgraph tracer will show the return
> value of each function. This is useful to find/analyze a original error
> source in a
On Fri, Jan 11, 2019 at 06:07:49PM +, Liviu Dudau wrote:
> Hi Jonathan,
>
> I have a patch adding documentation for the AFBC modifiers supported
> by the DRM framework with an upcoming patch series. Patch has been
> out for review for a while, please pull.
Nowhere in this email do you say wha
On Mon, Jan 07, 2019 at 11:25:16AM -0800, Dave Hansen wrote:
> On 1/7/19 6:15 AM, Matthew Wilcox wrote:
> > You're going to get data corruption doing this. try_to_unmap_one()
> > does:
> >
> > /* Move the dirty bit to the page. Now the pte is gone. */
&
On Mon, Jan 07, 2019 at 07:37:11PM +0100, Pavel Machek wrote:
> Is it "Device Tree" or "device tree"?
>
> pavel@duo:/data/l/k/Documentation$ grep -r "Device Tree" | wc -l
> 235
> pavel@duo:/data/l/k/Documentation$ grep -r "device tree" | wc -l
> 595
You missed ...
$ git grep -r "Device
On Mon, Jan 07, 2019 at 11:07:47AM -0500, Waiman Long wrote:
> > Why are you caching the _output_ of calling sprintf(), rather than caching
> > the
> > values of each interrupt?
> >
> It is just faster to dump the whole string buffer than redoing the
> number formatting each time when the values d
On Mon, Jan 07, 2019 at 10:12:58AM -0500, Waiman Long wrote:
> Reading /proc/stat can be slow especially if there are many irqs and on
> systems with many CPUs as summation of all the percpu counts for each
> of the irqs is required. On some newer systems, there can be more than
> 1000 irqs per soc
On Mon, Jan 07, 2019 at 02:02:39PM +0100, Vincent Whitchurch wrote:
> +++ b/Documentation/sysctl/vm.txt
> @@ -222,6 +222,10 @@ To increase the number of objects freed by this
> operation, the user may run
> number of dirty objects on the system and create more candidates to be
> dropped.
>
> +
On Thu, Jan 03, 2019 at 04:39:57PM -0800, Bart Van Assche wrote:
> @@ -571,50 +571,11 @@ item, explaining its use.
> 9) You've made a mess of it
> ---
>
> -That's OK, we all do. You've probably been told by your long-time Unix
> -user helper that ``GNU emacs`` automatic
On Wed, Jan 02, 2019 at 03:57:58PM -0500, Michael S. Tsirkin wrote:
> @@ -875,6 +893,8 @@ to the CPU containing it. See the section on "Multicopy
> atomicity"
> for more information.
>
>
> +
> +
> In summary:
>
>(*) Control dependencies can order prior loads against later stores.
Was
On Sat, Dec 29, 2018 at 07:05:18PM +0100, Otto Sabart wrote:
> Fix "reference to nonexisting document" warnings.
>
> Signed-off-by: Otto Sabart
Fixes: b255e500c8dc ("net: documentation: build a directory structure for
drivers")
On Tue, Nov 27, 2018 at 10:40:21AM -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2018 at 08:33:49PM +0100, Andrea Parri wrote:
> > On Mon, Nov 26, 2018 at 04:52:14PM +, Will Deacon wrote:
> > > David Laight explains:
> > >
> > > | A long time ago there was a document from Intel that said
On Sat, Nov 24, 2018 at 09:20:38AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git master
>
> commit dad4f140edaa3f6bb452b6913d41af1ffd672e45
I think
On Thu, Nov 22, 2018 at 10:34:56AM -0500, Shreyans Devendra Doshi wrote:
> Fixes a spelling error and removes an extra whitespace character.
There is a fierce battle amongst those who insist on one space after a
full stop and those who insist on two. I recommend not getting caught
up in this batt
On Thu, Nov 22, 2018 at 09:27:02PM +0200, Igor Stoppa wrote:
> I have studied the code involved with Nadav's patchset.
> I am perplexed about these sentences you wrote.
>
> More to the point (to the best of my understanding):
>
> poking_init()
> -
> 1. it gets one random poking addr
On Wed, Nov 21, 2018 at 12:38:20PM -0800, Daniel Colascione wrote:
> On Wed, Nov 21, 2018 at 12:31 PM Matthew Wilcox wrote:
> >
> > On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote:
> > > This change adds a per-pid-namespace 64-bit generation number,
On Wed, Nov 21, 2018 at 12:14:44PM -0800, Daniel Colascione wrote:
> This change adds a per-pid-namespace 64-bit generation number,
> incremented on PID rollover, and exposes it via a new proc file
> /proc/pid_generation. By examining this file before and after /proc
> enumeration, user code can de
On Wed, Nov 21, 2018 at 01:35:19AM +0100, Federico Vaga wrote:
> Some documents are refering to others without links. With this
> patch I add those missing links.
I am a neophyte to ReST, but ...
> +++ b/Documentation/dev-tools/coccinelle.rst
> @@ -4,6 +4,8 @@
>
> .. highlight:: none
>
> +..
On Tue, Nov 20, 2018 at 09:48:27AM -0800, Daniel Colascione wrote:
> On Tue, Nov 20, 2018 at 9:39 AM Matthew Wilcox wrote:
> > We have a limit on the number of FDs a process can have open for a reason.
> > Well, for many reasons.
>
> And the typical limit is too low. (I&#x
On Tue, Nov 20, 2018 at 10:18:29AM +0100, Pavel Machek wrote:
> > would ever rely on the pid being reused while having the descriptor
> > open. How would that make sense?
>
> I agree this is corner space, but users might be surprised that
> keeping FDs of /proc/pid/X would lead to PID space exhaus
I just went looking for the memory allocation guide in the MM docs instead
of in the core API. For the benefit of the next person who makes that
mistake, link to it from the MM docs.
Signed-off-by: Matthew Wilcox
diff --git a/Documentation/core-api/memory-allocation.rst
b/Documentation/core
On Sun, Nov 18, 2018 at 05:19:04PM -0800, Matthew Wilcox wrote:
> On Mon, Nov 19, 2018 at 09:08:20AM +0800, kernel test robot wrote:
> > Greetings,
> >
> > 0day kernel testing robot got the below dmesg and the first bad commit is
>
> Umm. I don't see a 'susp
On Mon, Nov 19, 2018 at 09:08:20AM +0800, kernel test robot wrote:
> Greetings,
>
> 0day kernel testing robot got the below dmesg and the first bad commit is
Umm. I don't see a 'suspicious RCU usage' message in here. I see a
lot of vmalloc warnings ... ?
> [7.699777] swapper: vmalloc: allo
On Wed, Nov 14, 2018 at 10:17:00PM +0100, David Hildenbrand wrote:
> Rename PG_balloon to PG_offline. This is an indicator that the page is
> logically offline, the content stale and that it should not be touched
> (e.g. a hypervisor would have to allocate backing storage in order for the
> guest t
On Mon, Nov 12, 2018 at 04:28:40AM -0800, Greg Kroah-Hartman wrote:
> On Mon, Nov 12, 2018 at 10:56:21AM +0100, Paolo Valente wrote:
> > From: Angelo Ruocco
> >
> > The kernfs pseudo file system doesn't export any function to only find
> > a node by name, without also getting a reference on it.
>
On Tue, Nov 13, 2018 at 02:13:44AM +0300, Timofey Titovets wrote:
> Some numbers from different not madvised workloads.
> Formulas:
> Percentage ratio = (pages_sharing - pages_shared)/pages_unshared
> Memory saved = (pages_sharing - pages_shared)*4/1024 MiB
> Memory used = free -h
>
> * Na
On Mon, Nov 12, 2018 at 12:26:10AM +0300, Timofey Titovets wrote:
> ksm by default working only on memory that added by
> madvice().
>
> And only way get that work on other applications:
> - Use LD_PRELOAD and libraries
> - Patch kernel
>
> Lets use kernel task list in ksm_scan_thread and add l
On Fri, Nov 09, 2018 at 03:11:31PM -0500, Waiman Long wrote:
> The mixing in of a sequence number into the IPC IDs is probably to
> avoid ID reuse in userspace as much as possible. With ipcmni_extend
> mode, the number of usable sequence numbers is greatly reduced leading
> to higher chance of ID r
On Fri, Nov 09, 2018 at 09:13:32AM -0800, Dave Hansen wrote:
> On 11/8/18 4:32 PM, Matthew Wilcox wrote:
> >> Now, looking at Yu-cheng's specific example, it doesn't matter. We've
> >> got 64-bit types and natural 64-bit alignment. Without __packed, we
> &g
On Thu, Nov 08, 2018 at 03:35:02PM -0800, Dave Hansen wrote:
> On 11/8/18 2:00 PM, Matthew Wilcox wrote:
> > struct a {
> > char c;
> > struct b b;
> > };
> >
> > we want struct b to start at offset 8, but with __packed, it will start
> > at of
On Thu, Nov 08, 2018 at 01:48:54PM -0800, Dave Hansen wrote:
> On 11/8/18 1:22 PM, Andy Lutomirski wrote:
> >> +struct cet_kernel_state {
> >> + u64 kernel_ssp; /* kernel shadow stack */
> >> + u64 pl1_ssp;/* ring-1 shadow stack */
> >> + u64 pl2_ssp;/* ring-2 shadow stack
On Thu, Nov 08, 2018 at 01:42:41PM +, David Laight wrote:
> From: Matthew Wilcox
> > On Thu, Nov 08, 2018 at 12:02:49PM +, David Laight wrote:
> > > This can be mitigated by only allocating 'big' numbers on systems
> > > that have a lot of pids.
> &g
On Thu, Nov 08, 2018 at 12:02:49PM +, David Laight wrote:
> From: Martin Steigerwald
> > Sent: 07 November 2018 17:05
> ...
> > Its not quite on-topic, but I am curious now: AFAIK PID limit is 16
> > bits. Right? Could it be raised to 32 bits? I bet it would be a major
> > change throughout dif
On Wed, Nov 07, 2018 at 05:30:22PM +, vitor wrote:
> Hi Matthew,
>
>
> On 07/11/18 17:05, Matthew Wilcox wrote:
> > On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:
> > > Add driver for Synopsys DesignWare I3C master IP
> > The so-call
On Tue, Nov 06, 2018 at 08:01:13AM +0200, Mike Rapoport wrote:
> > diff --git a/Documentation/filesystems/proc.txt
> > b/Documentation/filesystems/proc.txt
> > index 12a5e6e693b6..0b14460f721d 100644
> > --- a/Documentation/filesystems/proc.txt
> > +++ b/Documentation/filesystems/proc.txt
> > @@ -
On Mon, Oct 29, 2018 at 10:06:56AM +, Vitor soares wrote:
> Add driver for Synopsys DesignWare I3C master IP
The so-called "data sheet" (actually just an advertising brochure)
on your website claims DMA support. I don't see that support
anywhere in this driver.
On Tue, Nov 06, 2018 at 07:53:05AM -0800, Matthew Wilcox wrote:
> > -This feature is enabled by the CONFIG_INTEL_RDT Kconfig and the
> > -X86 /proc/cpuinfo flag bits:
> > +This feature is enabled by the CONFIG_INTEL_RDT Kconfig(for Intel) or
> > +CONFIG_AMD_QOS(for AMD) a
On Tue, Nov 06, 2018 at 03:41:26PM +, Moger, Babu wrote:
> @@ -1,4 +1,7 @@
> -User Interface for Resource Allocation in Intel Resource Director Technology
> +User Interface for RESCTRL feature
"for Resource Control".
> +Intel refers to this feature as Intel Resource Director Technology(Intel(
On Mon, Nov 05, 2018 at 10:43:43AM -0500, Waiman Long wrote:
> The maximum number of unique System V IPC identifiers was limited to
> 32k. That limit should be big enough for most use cases.
>
> However, there are some users out there requesting for more, especially
> those that are migrating fro
On Mon, Nov 05, 2018 at 10:43:46AM -0500, Waiman Long wrote:
> The idea of using the cyclic mode to reduce id reuse came from Manfred
> Spraul . There may be a little bit of
> additional memory/performance overhead in doing cyclic id allocation,
> but it is a slow path anyway and a bit of overhead
On Mon, Nov 05, 2018 at 09:58:15PM +0200, Mike Rapoport wrote:
> @@ -21,10 +21,10 @@ Virtual Memory Primer
> The physical memory in a computer system is a limited resource and
> even for systems that support memory hotplug there is a hard limit on
> the amount of memory that can be installed. Th
On Wed, Oct 31, 2018 at 10:36:59AM +0100, Peter Zijlstra wrote:
> On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
> > On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
> > > > On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
> > > I suppor
On Tue, Oct 30, 2018 at 11:55:46PM +0200, Igor Stoppa wrote:
> On 30/10/2018 23:25, Matthew Wilcox wrote:
> > On Tue, Oct 30, 2018 at 11:51:17AM -0700, Andy Lutomirski wrote:
> > > Finally, one issue: rare_alloc() is going to utterly suck
> > > performance-wise due
On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
> On 30/10/2018 21:20, Matthew Wilcox wrote:
> > > > So the API might look something like this:
> > > >
> > > > void *p = rare_alloc(...); /* writable pointer */
> > > >
On Tue, Oct 30, 2018 at 11:51:17AM -0700, Andy Lutomirski wrote:
> Finally, one issue: rare_alloc() is going to utterly suck
> performance-wise due to the global IPI when the region gets zapped out
> of the direct map or otherwise made RO. This is the same issue that
> makes all existing XPO effor
On Tue, Oct 30, 2018 at 12:28:41PM -0600, Tycho Andersen wrote:
> On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
> > On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
> > > > On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
> > > I suppor
1 - 100 of 180 matches
Mail list logo
