<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
<br>
Second, about pio.<br>
<br>
I believe that long term its headed out of Lustre. It only improves performance in a limited way in certain circumstances, and harms it in various others. So its off by default, and, I suspect, remains completely unused. A while back I noticed its test
framework test didnt activate it correctly, and once fixed, it sometimes deadlocks (race with truncate). Theres a patch to fix that, but a problem was found in it and it has since languished.<br>
<br>
I would still suggest you take it, Neil, as othewise youll complicate a bunch of potentially nasty porting working in the CLIO stack, as you apply the years of patches written with it there. Instead, Id suggest we pull it in the open sfs branch (Sorry!
It was a promising idea but it hasnt panned out, and the current parallel readahead work isnt going to use it.) and then eventually you could pick that up.<br>
<br>
Curious how folks feel about this. Id be willing to take a stab at writing a removal patch for 2.13. It pains me a bit to suggest giving up on it, but Jinshan and I want to do write container type work to improve writes, and theres the older/new again DDN
parallel readahead work for reads.<br>
<br>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of Patrick Farrell <paf@cray.com><br>
<b>Sent:</b> Tuesday, November 27, 2018 7:51:02 AM<br>
<b>To:</b> Andreas Dilger; NeilBrown<br>
<b>Cc:</b> Lustre Development List<br>
<b>Subject:</b> Re: [lustre-devel] [PATCH 10/12] lustre: clio: Introduce parallel tasks framework</font>
<div> </div>
</div>
<div>Two notes coming, first about padata.<br>
<br>
A major reason is actually the infrastructure itself - its inappropriate to our kinds of tasks. I did a quick talk on it a while back, intending then to fix it, but never got the chance (and since had better ideas to improve write performance):<br>
<br>
https://www.eofs.eu/_media/events/devsummit17/patrick_farrell_laddevsummit_pio.pdf<br>
<br>
padata basically bakes in a set of assumptions that amount to functionally infinite amount of small work units and a dedicated machine, which fit well with its role in packet encryption but dont sit well for other kinds of paralelliziation. (For example,
all work is strictly and explicitly bound to a CPU. No scheduler. One more as a bonus - it distributes work across all allowed CPUs, but that means if you have a small number of work items (which splitting I/O tends to be because you have to make relatively
big chunks) that effectively every work unit starts a worker thread for itself.)<br>
<br>
The recent discussion of a new parallel inaction framework on LWN looked intriguing for future work. its expected to fix a number of the limitations.<br>
https://lwn.net/Articles/771169/<br>
<br>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> lustre-devel <lustre-devel-bounces@lists.lustre.org> on behalf of Andreas Dilger <adilger@whamcloud.com><br>
<b>Sent:</b> Monday, November 26, 2018 11:08:45 PM<br>
<b>To:</b> NeilBrown<br>
<b>Cc:</b> Lustre Development List<br>
<b>Subject:</b> Re: [lustre-devel] [PATCH 10/12] lustre: clio: Introduce parallel tasks framework</font>
<div> </div>
</div>
<div class="x_BodyFragment"><font size="2"><span style="font-size:11pt">
<div class="x_PlainText">On Nov 26, 2018, at 21:20, NeilBrown <neilb@suse.com> wrote:<br>
> <br>
> On Sun, Nov 25 2018, James Simmons wrote:<br>
> <br>
>> From: Dmitry Eremin <dmitry.eremin@intel.com><br>
>> <br>
>> In this patch new API for parallel tasks execution is introduced.<br>
>> This API based on Linux kernel padata API which is used to perform<br>
>> encryption and decryption on large numbers of packets without<br>
>> reordering those packets.<br>
>> <br>
>> It was adopted for general use in Lustre for parallelization of<br>
>> various functionality. The first place of its usage is parallel I/O<br>
>> implementation.<br>
>> <br>
>> The first step in using it is to set up a cl_ptask structure to<br>
>> control of how this task are to be run:<br>
>> <br>
>> #include <cl_ptask.h><br>
>> <br>
>> int cl_ptask_init(struct cl_ptask *ptask, cl_ptask_cb_t cbfunc,<br>
>> void *cbdata, unsigned int flags, int cpu);<br>
>> <br>
>> The cbfunc function with cbdata argument will be called in the process<br>
>> of getting the task done. The cpu specifies which CPU will be used for<br>
>> the final callback when the task is done.<br>
>> <br>
>> The submission of task is done with:<br>
>> <br>
>> int cl_ptask_submit(struct cl_ptask *ptask,<br>
>> struct cl_ptask_engine *engine);<br>
>> <br>
>> The task is submitted to the engine for execution.<br>
>> <br>
>> In order to wait for result of task execution you should call:<br>
>> <br>
>> int cl_ptask_wait_for(struct cl_ptask *ptask);<br>
>> <br>
>> The tasks with flag PTF_ORDERED are executed in parallel but complete<br>
>> into submission order. So, waiting for last ordered task you can be sure<br>
>> that all previous tasks were done before this task complete.<br>
>> <br>
>> This patch differs from the OpenSFS tree by adding this functional<br>
>> to the clio layer instead of libcfs.<br>
> <br>
> While you are right that it shouldn't be in libcfs, it actually<br>
> shouldn't exist at all.<br>
> cfs_ptask_init() is used precisely once in OpenSFS. There is no point<br>
> creating a generic API wrapper like this that is only used once.<br>
> <br>
> cl_oi needs to use padata API calls directly.<br>
<br>
This infrastructure was also going to be used for parallel readahead, but the patch that implemented that was never landed because the expected performance gains didn't materialize.<br>
<br>
Cheers, Andreas<br>
---<br>
Andreas Dilger<br>
Principal Lustre Architect<br>
Whamcloud<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
lustre-devel mailing list<br>
lustre-devel@lists.lustre.org<br>
<a href="http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org">http://lists.lustre.org/listinfo.cgi/lustre-devel-lustre.org</a><br>
</div>
</span></font></div>
</div>
</body>
</html>