ntfs3.lists.linux.dev archive mirror
 help / color / mirror / Atom feed
From: Kari Argillander <kari.argillander@gmail.com>
To: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Cc: ntfs3@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org
Subject: fs/ntfs3: Runtree implementation with rbtree or others
Date: Fri, 10 Sep 2021 21:12:27 +0300	[thread overview]
Message-ID: <20210910181227.4tr3xn2aooeo2lvw@kari-VirtualBox> (raw)

Hello.

Konstantin you have wrote in ntfs_fs.h in struct runs_tree:

/* TODO: Use rb tree instead of array. */
struct runs_tree {
	struct rb_root root;

	struct ntfs_run *runs;
	size_t count; /* Currently used size a ntfs_run storage. */
	size_t allocated; /* Currently allocated ntfs_run storage size. */
};


But right now it is not array. It is just memory. Probably some early
comment, but I check that little bit and I think rb tree may not be good
choice. Right now we allocate more memory with kvmalloc() and then make
space for one entry with memmove. I do not quite understand why cannot
memory be other way around. This way we do not memmove. We can just put
new entry to other end right?

Also one thing what comes to my mind is to allocate page at the time. Is
there any drawbacks? If we do this with rb_tree we get many small entrys
and it also seems to problem. Ntfs-3g allocate 4kiB at the time. But
they still reallocate which I think is avoidable.

Also one nice trick with merging two run_tree togethor would be not to
allocate new memory for it but just use pointer to other list. This way
we can have big run_tree but it is in multi page. No need to reallocate
with this strategy. 

I just want some thoughts about this before starting implementation. If
you think rb_tree would be right call then I can do that. It just seems
to me that it might not be. But if search speed is big factor then it
might be. I just do not yet understand enogh that I can fully understand
benefits and drawbacks.

  Argillander


             reply	other threads:[~2021-09-10 18:12 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10 18:12 Kari Argillander [this message]
2021-09-15 15:44 ` fs/ntfs3: Runtree implementation with rbtree or others Konstantin Komarov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20210910181227.4tr3xn2aooeo2lvw@kari-VirtualBox \
    --to=kari.argillander@gmail.com \
    --cc=almaz.alexandrovich@paragon-software.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ntfs3@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).