'get_free_segments()' is implemented by traversing all segments to
calculate the total free segments. It cosume much time.
Every time when call 'find_next_free_block()' this calculation will
do it again. So if we cache the free segments count, it will greatly
improve performance of dfrag & resize
If the segment type is not matched, goto next segment to save time.
---
fsck/mount.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/fsck/mount.c b/fsck/mount.c
index e4372cf..098e73d 100644
--- a/fsck/mount.c
+++ b/fsck/mount.c
@@ -2852,8 +2852,10 @@ next_segment:
The performance flame graph of resize shows that 'get_free_segments()' consum
most user space time:
https://linkthinking.cn/images/resize_flame.jpg
Every calling 'get_free_segments()', it will traverses all segments to calculate
the free segments count. And this path is called a lot in resize & sl
Use IS_CUR_SEGNO() here can make code more concise and readable.
---
fsck/mount.c | 10 +-
1 file changed, 1 insertion(+), 9 deletions(-)
diff --git a/fsck/mount.c b/fsck/mount.c
index df0314d..e4372cf 100644
--- a/fsck/mount.c
+++ b/fsck/mount.c
@@ -2532,16 +2532,8 @@ void build_sit_area
While working on the multigrain timestamp changes, Linus suggested
adding some similar wrappers for accessing the atime and mtime that we
have for the ctime. With that, we could then move to using discrete
integers instead of timespec64 in struct inode, and shrink it.
Linus suggested using macros
Recently, we converted the ctime accesses in the kernel to use new
accessor functions. Linus recently pointed out though that if we add
accessors for the atime and mtime, then that would allow us to
seamlessly change how these timestamps are stored in the inode.
Add new accessor functions for the
Signed-off-by: Jeff Layton
---
fs/f2fs/dir.c | 6 +++---
fs/f2fs/f2fs.h | 10 ++
fs/f2fs/file.c | 14 +++---
fs/f2fs/inline.c | 2 +-
fs/f2fs/inode.c| 20 ++--
fs/f2fs/namei.c| 4 ++--
fs/f2fs/recovery.c | 8
fs/f2fs/super.c|
Make it clear that these fields are private now, and that the accessors
should be used instead.
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 12d247b82aa0..8316570
This shaves 8 bytes off struct inode, according to pahole.
Signed-off-by: Jeff Layton
---
include/linux/fs.h | 32 +++-
1 file changed, 23 insertions(+), 9 deletions(-)
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 831657011036..de902ff2938b 100644
--- a
The recent change to use discrete integers instead of struct timespec64
in struct inode shaved 8 bytes off of it, but it also moves the i_lock
into the previous cacheline, away from the fields that it protects.
Move i_blocks up above the i_lock, which moves the new 4 byte hole to
just after the ti
On Thu, Sep 28, 2023 at 2:06 PM Jeff Layton wrote:
>
> The recent change to use discrete integers instead of struct timespec64
> in struct inode shaved 8 bytes off of it, but it also moves the i_lock
> into the previous cacheline, away from the fields that it protects.
>
> Move i_blocks up above t
On Thu, 2023-09-28 at 14:35 +0300, Amir Goldstein wrote:
> On Thu, Sep 28, 2023 at 2:06 PM Jeff Layton wrote:
> >
> > The recent change to use discrete integers instead of struct timespec64
> > in struct inode shaved 8 bytes off of it, but it also moves the i_lock
> > into the previous cacheline,
On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> This shaves 8 bytes off struct inode, according to pahole.
>
> Signed-off-by: Jeff Layton
FWIW, this is similar to the approach that Deepa suggested
back in 2016:
https://lore.kernel.org/lkml/1452144972-15802-3-git-send-email-deepa.ker...@gmai
On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote:
> On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> > This shaves 8 bytes off struct inode, according to pahole.
> >
> > Signed-off-by: Jeff Layton
>
> FWIW, this is similar to the approach that Deepa suggested
> back in 2016:
>
> https
On Thu, 2023-09-28 at 07:05 -0400, Jeff Layton wrote:
> This shaves 8 bytes off struct inode, according to pahole.
>
> Signed-off-by: Jeff Layton
> ---
> include/linux/fs.h | 32 +++-
> 1 file changed, 23 insertions(+), 9 deletions(-)
>
> diff --git a/include/linux/f
On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote:
> On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote:
> > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> > > This shaves 8 bytes off struct inode, according to pahole.
> > >
> > > Signed-off-by: Jeff Layton
> >
> > FWIW, this
On Thu, 2023-09-28 at 10:19 -0700, Darrick J. Wong wrote:
> On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote:
> > On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote:
> > > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> > > > This shaves 8 bytes off struct inode, according to pa
From: Daeho Jeong
We don't have lots of benefits from this, since block devices already
have page caches in the kernel. Moreover, this feature has some
stability issues corrupting metadata. So, we better make this deprecated.
Signed-off-by: Daeho Jeong
---
fsck/main.c | 18 +--
include/
On Thu, 2023-09-28 at 10:41 -0700, Linus Torvalds wrote:
> On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote:
> >
> > Move i_blocks up above the i_lock, which moves the new 4 byte hole to
> > just after the timestamps, without changing the size of the structure.
>
> I'm sure others have mentioned
On Thu, 28 Sept 2023 at 04:06, Jeff Layton wrote:
>
> Move i_blocks up above the i_lock, which moves the new 4 byte hole to
> just after the timestamps, without changing the size of the structure.
I'm sure others have mentioned this, but 'struct inode' is marked with
__randomize_layout, so the ac
On Thu, Sep 28, 2023, at 13:40, Jeff Layton wrote:
> On Thu, 2023-09-28 at 10:19 -0700, Darrick J. Wong wrote:
>>
>> > I remember seeing those patches go by. I don't remember that change
>> > being NaK'ed, but I wasn't paying close attention at the time
>> >
>> > Looking at it objectively now, I
On Thu, Sep 28, 2023 at 01:40:55PM -0400, Jeff Layton wrote:
>
> Correct. We'd lose some fidelity in currently stored timestamps, but as
> Linus and Ted pointed out, anything below ~100ns granularity is
> effectively just noise, as that's the floor overhead for calling into
> the kernel. It's hard
On Thu, 28 Sept 2023 at 14:28, Theodore Ts'o wrote:
>
> I don't think anyone will complain about breaking the userspace API
> --- especially since if, say, the CIA was using this for their spies'
> drop boxes, they probably wouldn't want to admit it. :-)
Well, you will find that real apps do kin
On Thu, Sep 28, 2023 at 8:19 PM Darrick J. Wong wrote:
>
> On Thu, Sep 28, 2023 at 01:06:03PM -0400, Jeff Layton wrote:
> > On Thu, 2023-09-28 at 11:48 -0400, Arnd Bergmann wrote:
> > > On Thu, Sep 28, 2023, at 07:05, Jeff Layton wrote:
> > > > This shaves 8 bytes off struct inode, according to pa
On Fri, Sep 29, 2023 at 3:19 AM Linus Torvalds
wrote:
...
> So yes, real programs to cache stat information, and it matters for
> performance.
>
> But I don't think any actual reasonable program will have
> *correctness* issues, though -
I beg to disagree.
> because there are certainly filesyst
Jeff Layton wrote:
> Correct. We'd lose some fidelity in currently stored timestamps, but as
> Linus and Ted pointed out, anything below ~100ns granularity is
> effectively just noise, as that's the floor overhead for calling into
> the kernel. It's hard to argue that any application needs that
26 matches
Mail list logo
