similar to: RFC: async plugin support

Our cbdkit was branched from 1.1.12 with some patches from 1.1.13 added as well. The project has morphed significantly enough that a direct diff or merging between the two would not be feasible. Even the structure of the project directory and build has been changed to be in line with our other internal projects. I have uploaded the entire cbdkit source to our github at

On Fri, Jan 19, 2018 at 12:41:01PM -0500, Shaun McDowell wrote: [...] Thanks for the other email, I thought it was very interesting and I'm glad that people are looking at the performance of nbdkit seriously. > Our cbdkit was branched from 1.1.12 with some patches from 1.1.13 added as > well. The project has morphed significantly enough that a direct diff or > merging between the

Hi, We've been using a modified nbdkit (ours is cbdkit internally) for about half a year now and since you guys appear to be working on a next version of the API I wanted to go over some of the limitations we hit with nbdkit that we think others may also hit for consideration into the batch of changes you are making to the api. About Us: Our primary use for nbdkit is to facilitate a disk

Hi. I've been recently looking into asynchronous feature and currently stuck with few stuff that I would appreciate to get some help with. 1. I tried turning on the feature by setting 'server multi channel support = yes', 'aio read size = 1' and 'aio write size = 1' and I couldn't figure out whether it was really working or not. Is there any way I can verify this?

----- Forwarded message ----- Date: Sat, 18 Feb 2017 22:21:19 -0500 Subject: nbdkit async Hello, Hope this is the right person to contact regarding nbdkit design. I have a high latency massively parallel device that I am currently implementing as an nbdkit plugin in c++ and have run into some design limitations due to the synchronous callback interface nbdkit requires. Nbdkit is currently

On 01/19/2018 10:56 AM, Shaun McDowell wrote: > Limitation: The kernel will (with today's default settings) typically be > willing to send up to 128 requests of 128kB size to the driver in parallel. > We wanted to support 128 parallel read operations on different areas of the > disk without requiring 128 separate threads and connections for the driver. > Right now in nbdkit

On Fri, Jun 14, 2024 at 12:35:27PM GMT, Andr? Almeida wrote: > AMD hardware can do async flips with overlay planes, but currently there's no > easy way to enable that in DRM. To solve that, this patchset creates a new > drm_plane field, bool async_flip, that allows drivers to choose which plane can > or cannot do async flips. This is latter used on drm_atomic_set_property when >

On Fri, Jun 14, 2024 at 04:37:41PM -0300, Andr? Almeida wrote: > Hi Dmitry, > > Em 14/06/2024 14:32, Dmitry Baryshkov escreveu: > > On Fri, Jun 14, 2024 at 12:35:27PM GMT, Andr? Almeida wrote: > >> AMD hardware can do async flips with overlay planes, but currently there's no > >> easy way to enable that in DRM. To solve that, this patchset creates a new >

I''m pleased to announce the existence of async-observer. This is the very first public release. In the future I''ll confine announcements to the beanstalk-talk mailing list. WHAT IS ASYNC OBSERVER? ----------------------- Async Observer is a Rails plugin that provides deep integration with Beanstalk. beanstalkd is a fast, distributed, in-memory work-queue service. Its

On Fri, Jun 14, 2024 at 12:35:29PM GMT, Andr? Almeida wrote: > Drivers have different capabilities on what plane types they can or > cannot perform async flips. Create a plane::async_flip field so each > driver can choose which planes they allow doing async flips. > > Signed-off-by: Andr? Almeida <andrealmeid at igalia.com> > --- > drivers/gpu/drm/drm_atomic_uapi.c | 4

Hi David, > You're still using direct I/O with fio, which will likely disallow > client side caching with oplocks/leases. Is there a way to bypass this with settings in smb.conf at all and transform all writes to async? > I'd recommend checking that your (cifs.ko?) client is using a relatively > modern SMB2+ dialect and that leases are enabled on both sides. Yes, I

Hi Harry, On Monday 16 Jan 2017 16:13:39 Harry Wentland wrote: > On 2017-01-16 03:39 PM, Laurent Pinchart wrote: > > On Monday 16 Jan 2017 10:44:54 Andrey Grodzovsky wrote: > >> This series is a folow-up on > >> https://patchwork.kernel.org/patch/9501787/ > >> > >> The first patch makes changes to atomic helpers > >> to allow for drives with

Hi, On Thu, 18 Jul 2019 19:04:47 +0000, douxevip via samba wrote: > Hi, > > I have a ZFS dataset that has sync writes disabled (setting sync=disabled) which means that it will only do async writes, and sync requests get converted to async writes. The ZFS dataset is hosted on a single Samsung 840 Pro 512GB SATA SSD. > I have this same dataset served as a Samba share, using Proxmox VE

No need for filters to specify their model in two different ways; the callback alone is sufficient. Since all filters are in-tree, we can deal with the API/ABI change made here. Signed-off-by: Eric Blake <eblake@redhat.com> --- docs/nbdkit-filter.pod | 48 +++++++++++++++------------------ include/nbdkit-filter.h | 6 ++--- filters/cow/cow.c | 2 --

Thanks Ralph. Unfortunately that option doesn?t quite solve it. However even if it did, it?d still be good to add Async support for such queries. If there is WIP then I can look into finishing off the code myself. Can you point me to any branch that has this WIP? Looking through Samba source3 internals, it looks somewhat straightforward to add primitive support along the lines of Async pread,

Hi, On Fri, 19 Jul 2019 23:26:55 +0000, douxevip wrote: > So to summarize, this is the situation: > > 1) I run a fio benchmark requesting, small, random, async writes. Command is "fio --direct=1 --sync=0 --rw=randwrite --bs=4K --numjobs=1 --iodepth=1 --runtime=60 --group_reporting --name=sambatest --size=32k --time_based". I run this command on both the host, as on the Samba

Plugins cannot get rid of #define THREAD_MODEL (doing so would break API/ABI compatibility); however, we CAN add an optional callback for allowing a runtime reduction of the thread model. This can be especially useful for language bindings, as in the next patch, where the C glue code for the language has to cater to the maximum parallelism possible for that language, but where an individual plugin

We do not promise API stability for non-C languages; this is an API break as follows: instead of calling 'NBDKit.register_plugin model plugin' with a static model, you can now add .thread_model :(unit -> thread_model) to plugin or default to PARALLEL. Since all existing OCaml plugins will have already thought about thread models, they can convert their existing model into the new

Now that everything seems to rock I've hit the next hurdle. In my extensions.conf I have the extension: [agi-async] exten => _01XXXX,1,Agi(agi:async) and I can see that the context is "hit" when dialing into *. However my java app that's supposed to receive async agi events get no such events at all, but it does receive other manager API events. * version is 1.6.1.4

Commit 876d715e17a59bd25df53be34b942afd96e52da9 ("Refactor plugin_* functions into a backend struct.") causes hidden crashes in the test suite (which unfortunately don't cause tests to fail). These all come from handle_single_connection where we may lock the connection, run a single connection, free the backend, and then try to unlock the connection. Unfortunately the unlock