linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Oded Gabbay <oded.gabbay@gmail.com>
To: linux-kernel@vger.kernel.org, oshpigelman@habana.ai,
	ttayar@habana.ai, gregkh@linuxfoundation.org
Subject: [PATCH 0/9] habanalabs: support open device by multiple processes
Date: Sun, 28 Jul 2019 14:28:09 +0300	[thread overview]
Message-ID: <20190728112818.30397-1-oded.gabbay@gmail.com> (raw)

This patch-set removes the limitation in the driver's code that only a
single process will have a file-descriptor of the device at any point of
time.

This limitation needs to be removed because of two reasons:

1. Blocking multiple processes and trying to account them was stupid and
doomed to fail.

2. The driver needs to support system management applications that just
want to inquire about the device's status while a deep-learning
application is also running and sending work to the device.

With this patch-set, there can be unlimited number of open
file-descriptors of the device by unlimited number of user space
processes.

Having said that, only a single process can submit work to the device, or
do any change in the device itself via IOCTLs. All the processes can
perform inqueries about the device using the INFO IOCTL. This is enforced
by using an object called "context".

The "context" object is created as part of the private data the driver
saves per an open file-descriptor. For backward compatibility with
existing user-space code, the "context" is created in a lazy way (it is
created on the first call to an IOCTL). There can be only a single context
per process, and only a single context on the entire device is considered
"compute context". Only the FD which owns the "compute context" can
call IOCTLs which require this context, such as command submissions,
memory map, etc.

Only when an FD is completely released, its context will be closed. It
doesn't matter if the FD is duplicated or shared in user-space, as the
driver will keep a single private data structure (and single context) per
that FD.

In addition, a context that was open as a "non-compute context" can be
upgraded to a "compute context", if there isn't any other "compute
context". This is because the application usually calls the INOF IOCTL
before it calls other IOCTLs.

Thanks,
Oded

Oded Gabbay (9):
  habanalabs: add handle field to context structure
  habanalabs: verify context is valid in IOCTLs
  habanalabs: create context in lazy mode
  habanalabs: don't change frequency if user context is valid
  habanalabs: maintain a list of file private data objects
  habanalabs: define user context as compute context
  habanalabs: protect only pointer dereference in hard-reset
  habanalabs: kill user process after CS rollback
  habanalabs: allow multiple processes to open FD

 drivers/misc/habanalabs/command_buffer.c     |   6 +
 drivers/misc/habanalabs/command_submission.c |  12 ++
 drivers/misc/habanalabs/context.c            | 145 ++++++++++++++++---
 drivers/misc/habanalabs/debugfs.c            |   4 +-
 drivers/misc/habanalabs/device.c             | 144 +++++++++---------
 drivers/misc/habanalabs/goya/goya_hwmgr.c    |  11 +-
 drivers/misc/habanalabs/habanalabs.h         |  39 ++---
 drivers/misc/habanalabs/habanalabs_drv.c     |  54 ++-----
 drivers/misc/habanalabs/habanalabs_ioctl.c   |  20 ++-
 drivers/misc/habanalabs/memory.c             |   6 +
 10 files changed, 285 insertions(+), 156 deletions(-)

-- 
2.17.1


             reply	other threads:[~2019-07-28 11:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-28 11:28 Oded Gabbay [this message]
2019-07-28 11:28 ` [PATCH 1/9] habanalabs: add handle field to context structure Oded Gabbay
2019-07-28 11:28 ` [PATCH 2/9] habanalabs: verify context is valid in IOCTLs Oded Gabbay
2019-07-28 11:28 ` [PATCH 3/9] habanalabs: create context in lazy mode Oded Gabbay
2019-07-28 11:28 ` [PATCH 4/9] habanalabs: don't change frequency if user context is valid Oded Gabbay
2019-07-28 11:28 ` [PATCH 5/9] habanalabs: maintain a list of file private data objects Oded Gabbay
2019-07-28 11:28 ` [PATCH 6/9] habanalabs: define user context as compute context Oded Gabbay
2019-07-28 11:28 ` [PATCH 7/9] habanalabs: protect only pointer dereference in hard-reset Oded Gabbay
2019-07-28 11:28 ` [PATCH 8/9] habanalabs: kill user process after CS rollback Oded Gabbay
2019-07-28 11:28 ` [PATCH 9/9] habanalabs: allow multiple processes to open FD Oded Gabbay
2019-07-28 11:44   ` Greg KH
2019-07-28 11:56     ` Oded Gabbay
2019-07-28 12:04       ` Greg KH
2019-07-28 12:06         ` Oded Gabbay
2019-07-28 12:12           ` Greg KH
2019-07-28 12:18             ` Oded Gabbay

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190728112818.30397-1-oded.gabbay@gmail.com \
    --to=oded.gabbay@gmail.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=oshpigelman@habana.ai \
    --cc=ttayar@habana.ai \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).