On 4/10/2024 3:22 AM, David Hildenbrand wrote:
@@ -2200,7 +2200,22 @@ static inline size_t folio_size(struct folio *folio)
*/
static inline bool folio_likely_mapped_shared(struct folio *folio)
{
- return page_mapcount(folio_page(folio, 0)) > 1;
+ int mapcount = folio_mapcoun
On 4/10/2024 3:22 AM, David Hildenbrand wrote:
As we grow the code, the compiler might make stupid decisions and
unnecessarily degrade fork() performance. Let's make sure to always inline
functions that operate on a single PTE so the compiler will always
optimize out the loop and avoid a funct
On Wed, 17 Apr 2024 23:55:44 +0800 Heng Qi wrote:
> $ ethtool -c ethx
> ...
> rx-eqe-profile:
> {.usec = 1, .pkts = 256, .comps = 0,},
> {.usec = 8, .pkts = 256, .comps = 0,},
> {.usec = 64, .pkts = 256, .comps = 0,},
> {.usec = 128, .pkts = 256, .comps = 0,},
> {.usec = 256, .pkts = 2
On Thu, Apr 18, 2024 at 11:09 PM David Hildenbrand wrote:
>
> On 18.04.24 16:50, Lance Yang wrote:
> > Hey David,
> >
> > FWIW, just a nit below.
>
> Hi!
>
Thanks for clarifying!
> Thanks, but that was done on purpose.
>
> This way, we'll have a memory barrier (due to at least one
> atomic_inc_a
On 4/18/24 9:14 AM, Eric Biggers wrote:
On Sun, Apr 14, 2024 at 12:08:50PM -0500, Alex Elder wrote:
diff --git a/Documentation/process/coding-style.rst
b/Documentation/process/coding-style.rst
index 9c7cf73473943..bce43b01721cb 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documenta
On Thu, Apr 18, 2024 at 09:14:30AM -0700, Eric Biggers wrote:
> Also, it's not true that "Android" sets this option. It might be the case
> that
> some individual Android OEMs have decided to use it for some reason (they do
> have the ability to customize their kernel command line, after all). I
On Sun, Apr 14, 2024 at 12:08:50PM -0500, Alex Elder wrote:
> diff --git a/Documentation/process/coding-style.rst
> b/Documentation/process/coding-style.rst
> index 9c7cf73473943..bce43b01721cb 100644
> --- a/Documentation/process/coding-style.rst
> +++ b/Documentation/process/coding-style.rst
> @
On Mon, Apr 15, 2024 at 09:26:40AM -0700, Kees Cook wrote:
> On Mon, Apr 15, 2024 at 10:35:21AM +0200, Greg KH wrote:
> > On Mon, Apr 15, 2024 at 01:07:41AM -0700, Christoph Hellwig wrote:
> > > No, this advice is wronger than wrong. If you set panic_on_warn you
> > > get to keep the pieces.
> >
On 18.04.24 16:50, Lance Yang wrote:
Hey David,
FWIW, just a nit below.
Hi!
Thanks, but that was done on purpose.
This way, we'll have a memory barrier (due to at least one
atomic_inc_and_test()) between incrementing the folio refcount
(happening before the rmap change) and incrementing th
Hey David,
FWIW, just a nit below.
diff --git a/mm/rmap.c b/mm/rmap.c
index 2608c40dffad..08bb6834cf72 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1143,7 +1143,6 @@ static __always_inline unsigned int
__folio_add_rmap(struct folio *folio,
int *nr_pmdmapped)
{
atomic_t *ma
10 matches
Mail list logo
