aio: convert the ioctx list to radix tree

Date	Wed, 3 Apr 2013 16:20:48 +0300

When using a large number of threads performing AIO operations the
IOCTX list may get a significant number of entries which will cause
significant overhead. For example, when running this fio script:

rw=randrw; size=256k ;directory=/mnt/fio; ioengine=libaio; iodepth=1
blocksize=1024; numjobs=512; thread; loops=100

on an EXT2 filesystem mounted on top of a ramdisk we can observe up to
30% CPU time spent by lookup_ioctx:

 32.51%  [guest.kernel]  [g] lookup_ioctx
  9.19%  [guest.kernel]  [g] __lock_acquire.isra.28
  4.40%  [guest.kernel]  [g] lock_release
  4.19%  [guest.kernel]  [g] sched_clock_local
  3.86%  [guest.kernel]  [g] local_clock
  3.68%  [guest.kernel]  [g] native_sched_clock
  3.08%  [guest.kernel]  [g] sched_clock_cpu
  2.64%  [guest.kernel]  [g] lock_release_holdtime.part.11
  2.60%  [guest.kernel]  [g] memcpy
  2.33%  [guest.kernel]  [g] lock_acquired
  2.25%  [guest.kernel]  [g] lock_acquire
  1.84%  [guest.kernel]  [g] do_io_submit

This patchs converts the ioctx list to a radix tree. For a performance
comparison the above FIO script was run on a 2 sockets 8 core
machine. This are the results for the original list based
implementation and for the radix tree based implementation:

cores         1         2         4         8         16        32
list        111025 ms  62219 ms  34193 ms  22998 ms  19335 ms  15956 ms
radix        75400 ms  42668 ms  23923 ms  17206 ms  15820 ms  13295 ms
% of radix
relative      68%       69%       70%       75%       82%       83%
to list

To consider the impact of the patch on the typical case of having
only one ctx per process the following FIO script was run:

rw=randrw; size=100m ;directory=/mnt/fio; ioengine=libaio; iodepth=1
blocksize=1024; numjobs=1; thread; loops=100

on the same system and the results are the following:

list        65241 ms
radix       65402 ms
% of radix
relative    100.25%
to list

Cc: Andi Kleen <ak@linux.intel.com>

Signed-off-by: Octavian Purdila <octavian.purdila@intel.com>
modified for Mako hybrid from LKML

Signed-off-by: Paul Reioux <reioux@gmail.com>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
USB: ks_bridge: Enable autosuspend only for remote wakeup capable devices

USB core marks a device wakeup capable if it supports remote wakeup.
Check this wakeup capable flag before enabling autosuspend.

CRs-Fixed: 449097
Change-Id: I055bf5801859e4d83782916c71e0245c455becbf
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: mdm_ctrl_bridge: Do not unlink URB upon cable disconnect

MDM control bridge driver unlinks the pending URBs when control
bridge gets closed as a result of usb cable disconnect. Driver
sends set_control_line_state request to MDM upon bridge close.
Right after sending the setup request driver unlinks the pending
URBs. In case if the URB is unlinked after setup stage is completed,
status stage remains pending. This results in a control transfer
stall. Similarly, when the bridge is reopened as a result of USB
cable plug-in, the interrupt URB is not resubmitted, which can also
lead to a QMI stall since the MDM is waiting indefinitely to send
its response available notification. Fix these two potential stall
conditions by not unlinking URBs upon cable disconnect; this will
allow in-progress control transfers to finish gracefully and will
also allow notification interrupts to always be handled. Unlinking
of the URBs will happen during MDM device disconnect, instead of
upon bridge close.

CRs-Fixed: 419128,418478
Change-Id: I81690b2fd9e56b8f05a14945b0063080ca6dbd7b
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
USB: mdm_bridge: Fix a possible freed memory access

When tethered rmnet/dun interface probe is failed, the bridge channel
platform device is removed in error path.  The gadget driver schedule
a work to open the bridge channel in probe.  Cancel this work in remove
before closing the channel.

Cancel any pending work while closing the bridge.  Otherwise there is
a possibility of rx work running in parallel with probe error path.  If
this happens, rx work access already freed memory.

CRs-Fixed: 442119
(cherry picked from commit 50f3815166483c654ebb325c49e50af4e31547da)

Change-Id: I78c2ee04cfd083248127cfd6b9f07994087729ca
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: mdm_bridge: Increase the number of rx urbs

Due to higher HSIC interrupt threshold value, sometimes
driver is running short of enough rx urbs queued to HSIC
HW to receive IP packets from mdm device. In this case
driver is busy processing large number of completed rx
urbs and left with fewer pending urbs with HW. This causes
occasional throughput drops on rx data path. Hence increase
number of rx urb from 50 to 100, to keep HSIC HW busy in
pulling data from mdm device while completed urbs are getting
processed.

(cherry picked from commit e8f691f60db39b50951148c3e68ae35c89cdd397)
CRs-Fixed: 397809
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>

Change-Id: I590c203551c5ac83a71b8628d195f2a15840edf1
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: mdm_bridge: Fix race between disconnect and I/O completion handler

There is a possibility of race between device disconnect and I/O
completion handler. In this case disconnect frees bridge device
memory in thread context and I/O completion handler uses already
freed bridge device memory in interrupt context. Hence allocate
bridge device memory at the time of driver load and free it
during unload. Also, do not anchor interrupt and read urb and
unlink them synchronously to avoid accessing transfer buffers
associated to these urbs when driver disconnect frees them.

Guard the race condition by:-
1) Adding check for usb device disconnect state in the I/O
completion handler to avoid further processing I/O completion.

2) Unlinking tx urbs synchronously since asynchronous unlinking
results in the same race condition.

CRs-Fixed: 447591
Change-Id: Iae4c2a1920c16fcf3e1728144a7cfe6ca66c7705
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
USB: mdm_bridge: Simplify data bridge suspend/resume path

Synchronous runtime PM API is used to increment the PM usage counter
in Tx path.  It means Tx data path will not race with interface suspend.
Remove "delayed" anchor which is meant for Tx requests, that are arrived
during suspend.  There is no point in distinguishing auto suspend and
system wide suspend.  Abort suspend when we have pending Tx URBs.

CRs-Fixed: 451414
Change-Id: I302b120ccecfe30db1ebd2b1fcd9945a3675cf83
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
USB: mdm_bridge: Fix control bridge suspend

The current code does not abort suspend when there are pending URBs.
They are simply killed during suspend. This may lead to QMI stall.
Add proper checks to ensure that there is no pending Tx/Rx data
during suspend.  Clear the "SUSPENDED" flag in resume only after
taking out all the URBs from "tx_deferred" anchor.

CRs-Fixed: 451414
Change-Id: Icc48afc5eeedcc126d0ab1bec951bde4a53ac165
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: diag_bridge: Fix NULL pointer crash during disconnect

DIAG I/O could be executing concurrently when the device/interface
is disconnected. In such cases the usb_interface pointer could
become NULL while the read or write functions are about to access
it. Prevent these NULL pointer dereferences by guarding the
pointer with a mutex.

Change-Id: I0e2660dc53dae811e0a8686e69636808281ec53c
CRs-fixed: 393826
Signed-off-by: Jack Pham <jackp@codeaurora.org>
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: diag_bridge: call bridge callbacks even for -EPROTO.

The diagfwd_hsic driver acts as a client of the bridge and must
have its read/write callbacks called so it can properly free its
memory buffers. In the case of the HSIC device being disconnected,
the URB status is -EPROTO but the callback was withheld, which
led to lost buffers when the HSIC device is disconnected. Fix this
by always calling the callbacks, while continuing to treat -EPROTO
as a special case by returning -ENODEV on subsequent reads and
writes. Also fix a major but tiny gotcha in diagfwd's read function
in which the 'err' variable is additionally declared and used in a
local scope but is read outside it.

CRs-fixed: 394401
Signed-off-by: Jack Pham <jackp@codeaurora.org>

Conflicts:

	drivers/usb/misc/diag_bridge.c

Change-Id: Ic40e43555ba557ac0caf3abfd3b8e372eb522003
Signed-off-by: Neha Pandey <nehap@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
net: rmnet_ctrl_usb: Block file close until tx URBs are transmitted

Cherry picked from 16599ec35c3bc8965eb26d33cac044518df88c73

Rmnet control driver is directly killing tx URBs submitted to HSIC
HW if userspace closes the file. When a file is close, all pending
data needs to get flushed. Hence wait for the pending tx URBs to
finish transfer with a timeout before file close. This will complete
all the pending transfers gracefully on tx path so that mdm device
does not miss any control channel information upon file close.

Change-Id: I70942391056e57b0f6dd2cd5c16be2654759eabd
Signed-off-by: Hemant Kumar <hemantk@codeaurora.org>
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: gadget: u_ether: Fix memory corruption in TX path

When data aggregation is enabled, multiple skb buffers are copied
into a single USB request buffer.  When ever a USB request queue
is failed, make sure that req->length is reset to 0.  Otherwise
when the same request is used again, the stale length field is used
to access the request buffer.  This would lead to memory corruption.

The xmit function keeps the partial request at the beginning of the
queue.  Always put the idle request at the back of the queue.

CRs-Fixed: 469436
Change-Id: Idcd31e667b0bf261ab9a88f4a34464ccdf503e1b
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: gadget: u_data_hsic: Cancel pending MDM write work during remove

The HSIC bridge driver removes the data bridge platform device
during subsystem restart.  If gadget driver does not cancel pending
MDM write work, we end up accessing interface structure after it
is unbounded.

CRs-Fixed: 465383
Change-Id: I05fe3e2b625e87137681477aaaf1082ba1b81bae
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
usb: gadget: u_data_hsic: Use GFP_KERNEL where ever possible

The USB requests are allocated using dma pool API.  The dma pool has
limited memory for non-sleeping use case.  The current code does not
free USB requests during subsystem restart.  The requests are freed
only after cable is disconnected.  If subsystem restart happens
multiple  times without disconnecting cable, system may run out of the
dma pool memory.  This is leading to URB submission failures.  Use
GFP_KERNEL where ever possible.

CRs-Fixed: 463423
Change-Id: I0fca533e460e7b4234fe771e048e0e50494cb1da
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
USB: mdm_bridge: Fix probe error path

The platform device is not unregistered in probe error path.  The
platform device is added again during next probe and it fails.  But
the return value is not checked.  Kernel panic happens when platform
device is removed during disconnect.

CRs-Fixed: 465508
Change-Id: I4db613e72d8b405f10cde0d1335d231cf5079e64
Signed-off-by: Pavankumar Kondeti <pkondeti@codeaurora.org>
Signed-off-by: Derek Cannata <thederekjay@gmail.com>
Revert "board: mako: reduce reserver RAM for logs."

This reverts commit a441e6fd6cf43c7f1f127fd4c0ae11e01c4088a9.