<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body>
Two notes coming, first about padata.<br>
<br>
A major reason is actually the infrastructure itself - it’s 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 don’t 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. it’s expected to fix a number of the limitations.<br>
https://lwn.net/Articles/771169/<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 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="BodyFragment"><font size="2"><span style="font-size:11pt;">
<div class="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>
</body>
</html>