linux-kernel - RE: [PATCH 14/14] skd: remove skd

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 3 Oct 2013 12:00:56 +0000
From:	OS Engineering <osengineering@...c-inc.com>
To:	Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>,
	Ramprasad C <ramprasad.ch@...il.com>
CC:	"axboe@...nel.dk" <axboe@...nel.dk>,
	Akhil Bhansali <Akhil.Bhansali@...t.com>,
	"jmoyer@...hat.com" <jmoyer@...hat.com>,
	"kyungmin.park@...sung.com" <kyungmin.park@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	OS Engineering <osengineering@...c-inc.com>,
	Amit Phansalkar <Amit.Phansalkar@...t.com>,
	Ramprasad Chinthekindi <Ramprasad.Chinthekindi@...t.com>
Subject: RE: [PATCH 14/14] skd: remove skd_bio code



> -----Original Message-----
> From: Bartlomiej Zolnierkiewicz [mailto:b.zolnierkie@...sung.com]
> Sent: Tuesday, October 01, 2013 10:01 PM
> To: Ramprasad C
> Cc: axboe@...nel.dk; Akhil Bhansali; jmoyer@...hat.com;
> kyungmin.park@...sung.com; linux-kernel@...r.kernel.org; OS
> Engineering; Amit Phansalkar
> Subject: Re: [PATCH 14/14] skd: remove skd_bio code
> 
> 
> Hi Ramprasad,
> 
> On Tuesday, October 01, 2013 06:46:00 PM Ramprasad C wrote:
> > Hi Bartlomiej,
> >
> > Thank for your contributions to skd driver.
> >
> > The reason why skd driver has two code paths is:-
> > 1. For some workloads, Bio code path (skd_bio=1) performs better as
> > compared to default code, like random r/w, high queue depths, direct
> i/o
> > etc. In Bio code path, driver bypasses linux block elevator +
> scheduler
> > layers and 'struct bio' comes directly to driver through
> make_request_fn().
> 
> Have you tried using "noop" I/O scheduler to alleviate the issue?
> 
> You need the kernel compiled with CONFIG_IOSCHED_NOOP=y (it is enabled
> by
> default) and then do i.e. "echo noop > /sys/block/skd0/queue/scheduler"
> to
> enable "noop" I/O scheduler for the skd0 block device.
> 
> > 2. For some workloads like buffered mode (app) i/o, the default code
> path
> > performs much better. Hence, both the code paths are kept with module
> > parameter. We would prefer to have both code paths.
> 
> It would be very useful to see some numbers for skd_bio=1 and skd_bio=0
> (with "noop" I/O scheduler enabled) for the affected workloads to see
> what
> kind of improvement is offered by skd_bio=1.
> 
> If the block layer queuing code is a problem even with "noop" I/O
> scheduler
> it would be much better try to identify and fix (if possible) the
> problem
> parts in the generic block layer code. This would benefit all SSD
> hardware
> used on Linux not only the one supported by skd driver.
> 
> Also it is very inflexible to require the driver re-load just to
> optimize
> it for some workload. I believe that a better solution (runtime
> selection
> of the mode of operation at the block layer level) can be provided if
> really necessary.
> 

Hi Bartlomiej,

There was performance gap with noop too. However, for noop with nomerge=1 and rotation=0, the performance difference is marginal.
We feel the skd_bio=1 code path can be removed and can keep the single (default) code path in the driver.

Regards,
Ramprasad


> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R&D Institute Poland
> Samsung Electronics
> 
> > Regards,
> > Ramprasad
> >
> >
> >
> > On Mon, Sep 30, 2013 at 6:55 PM, Bartlomiej Zolnierkiewicz <
> > b.zolnierkie@...sung.com> wrote:
> >
> > > skd_bio feature adds a possibility to use the internal bio list to
> process
> > > requests instead of using the normal block layer queueing
> functionality.
> > > Its potential advantages are unclear and if there are any it is
> better to
> > > identify and fix the block layer code deficiences instead. Moreover
> it
> > > introduces separate code-paths through the whole driver which are
> difficult
> > > to test properly and maintain in the long-term. Since it is
> currently not
> > > used unless explicitly enabled by module parameter just remove it.
> > >
> > > Cc: Akhil Bhansali <abhansali@...c-inc.com>
> > > Cc: Jeff Moyer <jmoyer@...hat.com>
> > > Signed-off-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@...sung.com>
> > > Signed-off-by: Kyungmin Park <kyungmin.park@...sung.com>
> > > ---
> > >  drivers/block/skd_main.c | 605
> > > ++++++-----------------------------------------
> > >  1 file changed, 76 insertions(+), 529 deletions(-)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/