>
> > -Original Message-
> > From: Namjae Jeon
> > Sent: Sunday, March 21, 2021 10:14 PM
> > To: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> > c...@vger.kernel.org
> > Cc: linux-cifsd-de...@lists.sourceforge.net; smfre...@gmail.com;
> > senozhat...@chromium.org;
> On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> > This adds file operations and buffer pool for cifsd.
>
> Some random notes:
>
> > +static void rollback_path_modification(char *filename) {
> > + if (filename) {
> > + filename--;
> > + *filename = '/';
>
On (21/03/22 17:09), Matthew Wilcox wrote:
> On Mon, Mar 22, 2021 at 06:03:21PM +0900, Sergey Senozhatsky wrote:
> > On (21/03/22 08:15), Matthew Wilcox wrote:
> > >
> > > What's the scenario for which your allocator performs better than slub
> > >
> >
> > IIRC request and reply buffers can be
On Mon, Mar 22, 2021 at 06:03:21PM +0900, Sergey Senozhatsky wrote:
> On (21/03/22 08:15), Matthew Wilcox wrote:
> >
> > What's the scenario for which your allocator performs better than slub
> >
>
> IIRC request and reply buffers can be up to 4M in size. So this stuff
> just allocates a number
> -Original Message-
> From: Namjae Jeon
> Sent: Sunday, March 21, 2021 10:14 PM
> To: linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org; linux-
> c...@vger.kernel.org
> Cc: linux-cifsd-de...@lists.sourceforge.net; smfre...@gmail.com;
> senozhat...@chromium.org;
On Mon, Mar 22, 2021 at 02:57:18PM +0100, Christoph Hellwig wrote:
> On Mon, Mar 22, 2021 at 06:03:21PM +0900, Sergey Senozhatsky wrote:
> > On (21/03/22 08:15), Matthew Wilcox wrote:
> > >
> > > What's the scenario for which your allocator performs better than slub
> > >
> >
> > IIRC request
On Mon, Mar 22, 2021 at 06:03:21PM +0900, Sergey Senozhatsky wrote:
> On (21/03/22 08:15), Matthew Wilcox wrote:
> >
> > What's the scenario for which your allocator performs better than slub
> >
>
> IIRC request and reply buffers can be up to 4M in size. So this stuff
> just allocates a number
On Mon, Mar 22, 2021 at 06:03:21PM +0900, Sergey Senozhatsky wrote:
> On (21/03/22 08:15), Matthew Wilcox wrote:
> >
> > What's the scenario for which your allocator performs better than slub
> >
>
> IIRC request and reply buffers can be up to 4M in size. So this stuff
> just allocates a number
On (21/03/22 10:04), Dan Carpenter wrote:
>
> On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> > +void *ksmbd_alloc(size_t size)
> > +{
> > + return kvmalloc(size, GFP_KERNEL | __GFP_ZERO);
>
>
> This patch adds a bunch of wrappers around kvmalloc(). Don't do that.
Agreed.
On (21/03/22 07:02), Al Viro wrote:
> On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> > +static struct ksmbd_file *__ksmbd_lookup_fd(struct ksmbd_file_table *ft,
> > + unsigned int id)
> > +{
> > + bool unclaimed = true;
> > + struct
On (21/03/22 08:15), Matthew Wilcox wrote:
>
> What's the scenario for which your allocator performs better than slub
>
IIRC request and reply buffers can be up to 4M in size. So this stuff
just allocates a number of fat buffers and keeps them around so that
it doesn't have to vmalloc(4M) for
On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> This adds file operations and buffer pool for cifsd.
Why do you want this buffer pool? Do you not trust the
slab allocator to be able to do its job? Because what you have
here looks slower than the slab allocator.
Let's follow this
On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> +void *ksmbd_alloc(size_t size)
> +{
> + return kvmalloc(size, GFP_KERNEL | __GFP_ZERO);
This patch adds a bunch of wrappers around kvmalloc(). Don't do that.
Just use kvmalloc() directly instead. They just make the code hard
On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> +static struct ksmbd_file *__ksmbd_lookup_fd(struct ksmbd_file_table *ft,
> + unsigned int id)
> +{
> + bool unclaimed = true;
> + struct ksmbd_file *fp;
> +
> + read_lock(>lock);
>
On Mon, Mar 22, 2021 at 02:13:42PM +0900, Namjae Jeon wrote:
> This adds file operations and buffer pool for cifsd.
Some random notes:
> +static void rollback_path_modification(char *filename)
> +{
> + if (filename) {
> + filename--;
> + *filename = '/';
What an odd
15 matches
Mail list logo
