Update timeconst.pl #5
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
When hardware is overloaded or when max number of clients are reached in driver or firmware, hardware error is sent to video client. This change is to replace hardware error with actual errors. CRs-fixed: 575852 Change-Id: I07e599f894a3716a3dc4fed5eb7c987311f5bdde Signed-off-by: Deepak Verma <dverma@codeaurora.org>
Firmware requires the max number of hier-p layers to be used during the encode session to be set in load resources state. Without this change, firmware will not enable hier-p encoding. Also switch to using HFI_PROPERTY_CONFIG_VENC_HIER_P_ENH_LAYER to set the number of hier-p layers. Change-Id: I1fbf835acdb7d0a06d33cf9c2d038fb87c10010d Signed-off-by: Arun Menon <avmenon@codeaurora.org>
Adds support to set initial qp, thereby allowing the client to set initial qp for I,P, and B frames. Change-Id: Ie956651bde85e800d97a0007769af9aec8ca16a4 Signed-off-by: Ashray Kulkarni <ashrayk@codeaurora.org> Conflicts: drivers/media/platform/msm/vidc/msm_venc.c
Add support and control for setting Active format description and closed caption meta data in the extradata. FW parses metadata and adds it to the extradata. Client can use control to parse extradata for the metadata information. Change-Id: I79fb71e635927c95e0792862c9dea7d96f58e895 Signed-off-by: Jayasena Sangaraboina <jsanga@codeaurora.org>
Add 8KB worth of padding for extradata. This is required to accommodate some of the larger extradata types that didn't fit into the residual space between the actual buffer size and its aligned size. CRs-Fixed: 647378 Change-Id: I550f806079dfbdece229f68ffdfc5c0e20b3c9e1 Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
Previously, the extradata size was included within VENUS_BUFFER_SIZE and callers (primarily in userspace) wouldn't know how much extra padding was added to the buffer size. Exposing it allows userspace to query directly instead of doing guesswork. Change-Id: I7f9701a4adfe364d757028514bdd4fa84402a995 Signed-off-by: Deva Ramasubramanian <dramasub@codeaurora.org>
0x8080 is gray color concealment, changing it to black color, which is 0x8010. Change-Id: I50897d771913ee33a5b2c2ea486996dfc0c294bf Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org> Conflicts: drivers/media/platform/msm/vidc/msm_vdec.c
Right now, input buffer size is calculated based on maximum supported height and width returned from FW. These values are not true representation as they are calculated for rotation usecase. Driver needs to use max MB supported from FW. This change fixes the same. CRs-Fixed: 599818 Change-Id: I5b5f7d0db1088a4bc16ec7a32b31e1f763d5da7c Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org>
Take the minimum of the size calculated by driver using max width and height supported and the size set by client for input buffers. Change interface to get input and output buffer sizes. Change-Id: Ia3eb4cc7ae7bb38e2650fff1b694623e2aab62ef Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org>
Removed clearing of interrupt mask register after the streamon is done add a reset logic for VFE after all the streams are inactive Change-Id: Ib8999baae8f75498dcc813aa01fbb44f8c104e94 CRs-Fixed: 583125 Signed-off-by: Chandan Gera <cgera@codeaurora.org> Conflicts: drivers/media/platform/msm/camera_v2/isp/msm_isp32.c
Cleanup the camera msm generic buffer manager list when all v4l2 nodes are closed. Change-Id: I27636533621d3329bcc5dffba8c003d2cdc252c2 CRs-Fixed: 599983 Signed-off-by: Azam Sadiq Pasha Kapatrala Syed <akapatra@codeaurora.org>
this is to support fr18291 manually set focus position Change-Id: Idec86177abc265c38fd48e18d1320c5ae40b7f03 Signed-off-by: Yongui Mao <yongguim@codeaurora.org>
Actuator user space driver requires lens position after move focus call returns. Return lens position as part cfg params for move focus ioctl. Change-Id: I8fdce16c192db8685b1a2ac66a2cba052d64423c Signed-off-by: Sreesudhan Ramakrish Ramkumar <srramku@codeaurora.org>
Queue output buffers without extradata to Venus. Venus is returning UPSCALE_NOT_SUPPORTED error when output2 size is bigger than output size. This change suppresses this error as it is not fatal. Change-Id: I8a3f708092b131400b88828f6c1a684f08b3f18a Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org>
This change flushes any queued work related to power collapse, once the device is power suspended. There are applications which do not destroy video instance on suspending the device. For such applications, if the device is power suspended, video driver does not prepare venus for power collapse. Considerable power saving is observed by power collapsing venus before the device goes in suspend state. Change-Id: I11252e45b10d0d3d3eefb38994acd083c847bbb8 Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org>
While seeking, FW returns all the buffers to host. In multi-stream usecase like downscaling, the o/p buffers need to be re-queued back to FW. Change-Id: I5ea8534c06b3e48dadd4d73ab4432a13687a99c1 CRs-Fixed: 631827 Signed-off-by: Vikash Garodia <vgarodia@codeaurora.org> Conflicts: drivers/media/platform/msm/vidc/msm_vdec.c
Memory allocation must be verified before proceeding. CRs-Fixed: 606522 Change-Id: I809acc21dcd5e680827feb5d0fa8f45814bf4773 Signed-off-by: Jorge Solano Altamirano <jsolano@codeaurora.org>
The input parameters may be null. This change adds input checks at function q6_hfi_iface_eventq_read CRs-Fixed: 606516 Change-Id: I801a9d3249e9b97fa218fc29bc3a2a0e7a0d4d3f Signed-off-by: Prasad Nallani <pnalla@codeaurora.org>
Modify Q6 HFI not to alter the core returned max supported width and height. Whereas venus HFI will alter the the max supported width and height to 1080p. Change-Id: I901862e8fc98a1a6d80e62e7ab2d6477de5f07a4 Signed-off-by: Ravi Kiran Vonteddu <rvontedd@codeaurora.org> Conflicts: drivers/media/platform/msm/vidc/msm_vidc_common.c drivers/media/platform/msm/vidc/venus_hfi.c drivers/media/platform/msm/vidc/vidc_hfi_api.h
Modify HFI not to alter firmware returned max supported width and height and make generic both for Venus and Q6. Remove creation of debugfs file for VP8 mode. Change-Id: I77d9077a79214d90f59eb7314bb66e310b5a418f Signed-off-by: Manikanta Sivapala <msivap@codeaurora.org>
This reverts commit d9a4140.
This reverts commit a66ddbd.
This reverts commit fa1b13f.
This reverts commit 4f8515f. Conflicts: drivers/media/platform/msm/camera_v2/msm_buf_mgr/msm_generic_buf_mgr.c drivers/media/platform/msm/camera_v2/msm_buf_mgr/msm_generic_buf_mgr.h
This patchset is for supporting LZ4 compression and the crypto API using
it.
As shown below, the size of data is a little bit bigger but compressing
speed is faster under the enabled unaligned memory access. We can use
lz4 de/compression through crypto API as well. Also, It will be useful
for another potential user of lz4 compression.
lz4 Compression Benchmark:
Compiler: ARM gcc 4.6.4
ARMv7, 1 GHz based board
Kernel: linux 3.4
Uncompressed data Size: 101 MB
Compressed Size compression Speed
LZO 72.1MB 32.1MB/s, 33.0MB/s(UA)
LZ4 75.1MB 30.4MB/s, 35.9MB/s(UA)
LZ4HC 59.8MB 2.4MB/s, 2.5MB/s(UA)
- UA: Unaligned memory Access support
- Latest patch set for LZO applied
This patch:
Add support for LZ4 compression in the Linux Kernel. LZ4 Compression APIs
for kernel are based on LZ4 implementation by Yann Collet and were changed
for kernel coding style.
LZ4 homepage : http://fastcompression.blogspot.com/p/lz4.html
LZ4 source repository : http://code.google.com/p/lz4/
svn revision : r90
Two APIs are added:
lz4_compress() support basic lz4 compression whereas lz4hc_compress()
support high compression or CPU performance get lower but compression
ratio get higher. Also, we require the pre-allocated working memory with
the defined size and destination buffer must be allocated with the size of
lz4_compressbound.
[akpm@linux-foundation.org: make lz4_compresshcctx() static]
Signed-off-by: Chanho Min <chanho.min@lge.com>
Cc: "Darrick J. Wong" <djwong@us.ibm.com>
Cc: Bob Pearson <rpearson@systemfabricworks.com>
Cc: Richard Weinberger <richard@nod.at>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>
Cc: Yann Collet <yann.collet.73@gmail.com>
Cc: Kyungsik Lee <kyungsik.lee@lge.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
(cherry picked from commit ae54eec1285f644c7acec9c4c0c3963178e93c3f)
The LZ4 code is listed as using the "BSD 2-Clause License". Signed-off-by: Richard Laager <rlaager@wiktel.com> Acked-by: Kyungsik Lee <kyungsik.lee@lge.com> Cc: Chanho Min <chanho.min@lge.com> Cc: Richard Yao <ryao@gentoo.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> [ The 2-clause BSD can be just converted into GPL, but that's rude and pointless, so don't do it - Linus ] Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit acea9a08809ac718b4e04063f6872067fcc2dbe6)
LZ4 compression and decompression functions require different in signedness input/output parameters: unsigned char for compression and signed char for decompression. Change decompression API to require "(const) unsigned char *". Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> Cc: Kyungsik Lee <kyungsik.lee@lge.com> Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Yann Collet <yann.collet.73@gmail.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> (cherry picked from commit 6d695cba0642a8c843dd1f9edc47accec5bb5a95)
Given some pathologically compressed data, lz4 could possibly decide to wrap a few internal variables, causing unknown things to happen. Catch this before the wrapping happens and abort the decompression. Reported-by: "Don A. Bailey" <donb@securitymouse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8664dea287c77a320eeaf42ace763e40b45ba449)
There is one other possible overrun in the lz4 code as implemented by Linux at this point in time (which differs from the upstream lz4 codebase, but will get synced at in a future kernel release.) As pointed out by Don, we also need to check the overflow in the data itself. While we are at it, replace the odd error return value with just a "simple" -1 value as the return value is never used for anything other than a basic "did this work or not" check. Reported-by: "Don A. Bailey" <donb@securitymouse.com> Reported-by: Willy Tarreau <w@1wt.eu> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 82fce7033b481e85fc1a9489d0b3a295a2afd446)
Jan points out that I forgot to make the needed fixes to the lz4_uncompress_unknownoutputsize() function to mirror the changes done in lz4_decompress() with regards to potential pointer overflows. The only in-kernel user of this function is the zram code, which only takes data from a valid compressed buffer that it made itself, so it's not a big issue. But due to external kernel modules using this function, it's better to be safe here. Reported-by: Jan Beulich <JBeulich@suse.com> Cc: "Don A. Bailey" <donb@securitymouse.com> Cc: stable <stable@vger.kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit d0c5ea7736728fbd7302902eafdcddfde286c7bf)
Add LZ4 compressor support. Enable it with CONFIG_ZRAM_LZ4_COMPRESS=y Change-Id: I4bb62c1b51be9171f03386a2b714c6f7542cf321 Signed-off-by: Chris Fries <cfries@motorola.com> Reviewed-on: http://gerrit.mot.com/694989 Tested-by: Jira Key <jirakey@motorola.com> Reviewed-by: Russell Knize <rknize@motorola.com> Submit-Approved: Jira Key <jirakey@motorola.com> (cherry picked from commit 1f81bd989451c95ee2461097056f3aee319f704d)
Set ARM_EFFICIENT_UNALIGNED_ACCESS to improve performance in lz4
compression and decompression.
On msm8x26 cortex-a7,
LZO LZ4 LZ4 w/ UA
decompress (bs=4k) 121.21 115.52 148.7
LZO LZ4 LZ4 w/ UA
compress (bs=4k) 37.5 34.5 44.8
Change-Id: I10dfea380f7558e29576d65f91c8cee13bf8e166
Signed-off-by: Chris Fries <cfries@motorola.com>
Reviewed-on: http://gerrit.mot.com/697567
Tested-by: Jira Key <jirakey@motorola.com>
Reviewed-by: Shashank Shekhar <shashankshekhar@motorola.com>
Reviewed-by: Igor Kovalenko <igork@motorola.com>
Submit-Approved: Jira Key <jirakey@motorola.com>
(cherry picked from commit 0fbb0d508f7904f0741a174de83f7aa2a65fa1a0)
Some occurences in the netfilter tree use skb_header_pointer() in the following way ... struct dccp_hdr _dh, *dh; ... skb_header_pointer(skb, dataoff, sizeof(_dh), &dh); ... where dh itself is a pointer that is being passed as the copy buffer. Instead, we need to use &_dh as the forth argument so that we're copying the data into an actual buffer that sits on the stack. Currently, we probably could overwrite memory on the stack (e.g. with a possibly mal-formed DCCP packet), but unintentionally, as we only want the buffer to be placed into _dh variable. Change-Id: Ib8ff9f1f0afd905aa31cef49ff8a60344a4624c6 Fixes: 2bc7804 ("[NETFILTER]: nf_conntrack: add DCCP protocol support") Signed-off-by: Daniel Borkmann <dborkman@redhat.com> Signed-off-by: Pablo Neira Ayuso <pablo@netfilter.org>
We need to protect the atomic acquisition in the kernel against rogue user space which sets the user space futex to 0, so the kernel side acquisition succeeds while there is existing state in the kernel associated to the real owner. Verify whether the futex has waiters associated with kernel state. If it has, return -EINVAL. The state is corrupted already, so no point in cleaning it up. Subsequent calls will fail as well. Not our problem. [ tglx: Use futex_top_waiter() and explain why we do not need to try restoring the already corrupted user space state. ] Change-Id: Idb5735bd185d010401525fcd419870558d7340c6 Signed-off-by: Darren Hart <dvhart@linux.intel.com> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Cc: stable@vger.kernel.org Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Git-commit: 550c7910f0e2fd4f130fec2f17541f3614fdfaf9 Git-repo: https://android.googlesource.com/kernel/common.git Signed-off-by: Ian Maund <imaund@codeaurora.org>
If the owner died bit is set at futex_unlock_pi, we currently do not cleanup the user space futex. So the owner TID of the current owner (the unlocker) persists. That's observable inconsistant state, especially when the ownership of the pi state got transferred. Clean it up unconditionally. Change-Id: I9b8da1438c61a7c30a11ad91550f00c0a7349129 Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: Kees Cook <keescook@chromium.org> Cc: Will Drewry <wad@chromium.org> Cc: Darren Hart <dvhart@linux.intel.com> Cc: stable@vger.kernel.org Git-commit: a2ec8e3dcdc6c93f574a0e22039b791cc5e14fa6 Git-repo: https://android.googlesource.com/kernel/common.git Signed-off-by: Ian Maund <imaund@codeaurora.org>
The current implementation of lookup_pi_state has ambigous handling of
the TID value 0 in the user space futex. We can get into the kernel
even if the TID value is 0, because either there is a stale waiters
bit or the owner died bit is set or we are called from the requeue_pi
path or from user space just for fun.
The current code avoids an explicit sanity check for pid = 0 in case
that kernel internal state (waiters) are found for the user space
address. This can lead to state leakage and worse under some
circumstances.
Handle the cases explicit:
Waiter | pi_state | pi->owner | uTID | uODIED | ?
[1] NULL | --- | --- | 0 | 0/1 | Valid
[2] NULL | --- | --- | >0 | 0/1 | Valid
[3] Found | NULL | -- | Any | 0/1 | Invalid
[4] Found | Found | NULL | 0 | 1 | Valid
[5] Found | Found | NULL | >0 | 1 | Invalid
[6] Found | Found | task | 0 | 1 | Valid
[7] Found | Found | NULL | Any | 0 | Invalid
[8] Found | Found | task | ==taskTID | 0/1 | Valid
[9] Found | Found | task | 0 | 0 | Invalid
[10] Found | Found | task | !=taskTID | 0/1 | Invalid
[1] Indicates that the kernel can acquire the futex atomically. We
came came here due to a stale FUTEX_WAITERS/FUTEX_OWNER_DIED bit.
[2] Valid, if TID does not belong to a kernel thread. If no matching
thread is found then it indicates that the owner TID has died.
[3] Invalid. The waiter is queued on a non PI futex
[4] Valid state after exit_robust_list(), which sets the user space
value to FUTEX_WAITERS | FUTEX_OWNER_DIED.
[5] The user space value got manipulated between exit_robust_list()
and exit_pi_state_list()
[6] Valid state after exit_pi_state_list() which sets the new owner in
the pi_state but cannot access the user space value.
[7] pi_state->owner can only be NULL when the OWNER_DIED bit is set.
[8] Owner and user space value match
[9] There is no transient state which sets the user space TID to 0
except exit_robust_list(), but this is indicated by the
FUTEX_OWNER_DIED bit. See [4]
[10] There is no transient state which leaves owner and user space
TID out of sync.
Backport to 3.13
conflicts: kernel/futex.c
Change-Id: Ic15b8229880892a36ebbdf6c693ffba26ea03b3b
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: John Johansen <john.johansen@canonical.com>
Cc: Kees Cook <keescook@chromium.org>
Cc: Will Drewry <wad@chromium.org>
Cc: Darren Hart <dvhart@linux.intel.com>
Cc: stable@vger.kernel.org
Git-commit: b50939f89dae691f8da9e0fd22e0eae0db1c0ae4
Git-repo: https://android.googlesource.com/kernel/common.git
Signed-off-by: Ian Maund <imaund@codeaurora.org>
commit 60916a9382e88fbf5e54fd36a3e658efd7ab7bed upstream.
syscall_get_nr can return -1 in the case that the task is not executing
a system call.
This patch fixes perf_syscall_{enter,exit} to check that the syscall
number is valid before using it as an index into a bitmap.
Link: http://lkml.kernel.org/r/1345137254-7377-1-git-send-email-will.deacon@arm.com
Change-Id: I010666b85491f1f282c9a7d56a3a23dd9a50e16a
Cc: Jason Baron <jbaron@redhat.com>
Cc: Wade Farnsworth <wade_farnsworth@mentor.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit 086ba77a6db00ed858ff07451bedee197df868c9 upstream.
ARM has some private syscalls (for example, set_tls(2)) which lie
outside the range of NR_syscalls. If any of these are called while
syscall tracing is being performed, out-of-bounds array access will
occur in the ftrace and perf sys_{enter,exit} handlers.
# trace-cmd record -e raw_syscalls:* true && trace-cmd report
...
true-653 [000] 384.675777: sys_enter: NR 192 (0, 1000, 3, 4000022, ffffffff, 0)
true-653 [000] 384.675812: sys_exit: NR 192 = 1995915264
true-653 [000] 384.675971: sys_enter: NR 983045 (76f74480, 76f74000, 76f74b28, 76f74480, 76f76f74, 1)
true-653 [000] 384.675988: sys_exit: NR 983045 = 0
...
# trace-cmd record -e syscalls:* true
[ 17.289329] Unable to handle kernel paging request at virtual address aaaaaace
[ 17.289590] pgd = 9e71c000
[ 17.289696] [aaaaaace] *pgd=00000000
[ 17.289985] Internal error: Oops: 5 [#1] PREEMPT SMP ARM
[ 17.290169] Modules linked in:
[ 17.290391] CPU: 0 PID: 704 Comm: true Not tainted 3.18.0-rc2+ #21
[ 17.290585] task: 9f4dab00 ti: 9e710000 task.ti: 9e710000
[ 17.290747] PC is at ftrace_syscall_enter+0x48/0x1f8
[ 17.290866] LR is at syscall_trace_enter+0x124/0x184
Fix this by ignoring out-of-NR_syscalls-bounds syscall numbers.
Commit cd0980f "tracing: Check invalid syscall nr while tracing syscalls"
added the check for less than zero, but it should have also checked
for greater than NR_syscalls.
Link: http://lkml.kernel.org/p/1414620418-29472-1-git-send-email-rabin@rab.in
Change-Id: I7107c6baae1983e17ac20d97cd3502e9a3867196
Fixes: cd0980f "tracing: Check invalid syscall nr while tracing syscalls"
Signed-off-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
[lizf: Backported to 3.4: adjust context]
Signed-off-by: Zefan Li <lizefan@huawei.com>
commit a3a8784454692dd72e5d5d34dcdab17b4420e74c upstream. When a key is being garbage collected, it's key->user would get put before the ->destroy() callback is called, where the key is removed from it's respective tracking structures. This leaves a key hanging in a semi-invalid state which leaves a window open for a different task to try an access key->user. An example is find_keyring_by_name() which would dereference key->user for a key that is in the process of being garbage collected (where key->user was freed but ->destroy() wasn't called yet - so it's still present in the linked list). This would cause either a panic, or corrupt memory. Fixes CVE-2014-9529. Change-Id: I22bee631f32f9296f9db612793150fa05e2534b4 Signed-off-by: Sasha Levin <sasha.levin@oracle.com> Signed-off-by: David Howells <dhowells@redhat.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Change-Id: I153d5f65ab1db689309b757b400678667ddf3a79
We have two problems in UDP stack related to bogus checksums : 1) We return -EAGAIN to application even if receive queue is not empty. This breaks applications using edge trigger epoll() 2) Under UDP flood, we can loop forever without yielding to other processes, potentially hanging the host, especially on non SMP. This patch is an attempt to make things better. We might in the future add extra support for rt applications wanting to better control time spent doing a recv() in a hostile environment. For example we could validate checksums before queuing packets in socket receive queue. Change-Id: I2757c483bd7b090ac8dd18178b5d0733a6711e1f Signed-off-by: Eric Dumazet <edumazet@google.com> Cc: Willem de Bruijn <willemb@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
This prevents a race between chown() and execve(), where chowning a setuid-user binary to root would momentarily make the binary setuid root. This patch was mostly written by Linus Torvalds. Signed-off-by: Jann Horn <jann@thejh.net> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Conflicts: fs/exec.c Change-Id: Iecebf23d07e299689e4ba4fd74ea8821ef96e72b
Change-Id: If7d2382c7920015c11a778d85c647688908f405d
Change-Id: I63e44f8764706f3675d03836c2292ce078db2e6e
FIOPS (Fair IOPS) ioscheduler is IOPS based ioscheduler, so only targets for drive without I/O seek. It's quite similar like CFQ, but the dispatch decision is made according to IOPS instead of slice. The algorithm is simple. Drive has a service tree, and each task lives in the tree. The key into the tree is called vios (virtual I/O). Every request has vios, which is calculated according to its ioprio, request size and so on. Task's vios is the sum of vios of all requests it dispatches. FIOPS always selects task with minimum vios in the service tree and let the task dispatch request. The dispatched request's vios is then added to the task's vios and the task is repositioned in the sevice tree. Unlike CFQ, FIOPS doesn't have separate sync/async queues, because with I/O less writeback, usually a task can only dispatch either sync or async requests. Bias read or write request can still be done with read/write scale. One issue is if workload iodepth is lower than drive queue_depth, IOPS share of a task might not be strictly according to its priority, request size and so on. In this case, the drive is in idle actually. Solving the problem need make drive idle, so impact performance. I believe CFQ isn't completely fair between tasks in such case too. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops read/write request scale read/write speed of Flash based storage usually is different. For example, in my SSD maxium thoughput of read is about 3 times faster than that of write. Add a scale to differenate read and write. Also add a tunable, so user can assign different scale for read and write. By default, the scale is 1:1, which means the scale is a noop. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops sync/async scale CFQ gives 2.5 times more share to sync workload. This matches CFQ. Note this is different with the read/write scale. We have 3 types of requests: 1. read 2. sync write 3. write CFQ doesn't differentitate type 1 and 2, but request cost of 1 and 2 are usually different for flash based storage. So we have both sync/async and read/write scale here. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops add ioprio support Add CFQ-like ioprio support. Priority A will get 20% more share than priority A+1, which matches CFQ. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops preserve vios key for deep queue depth workload If the task has running request, even it's added into service tree newly, we preserve its vios key, so it will not lost its share. This should work for task driving big queue depth. For single depth task, there is no approach to preserve its vios key. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops bias sync workload If there are async requests running, delay async workload. Otherwise async workload (usually very deep iodepth) will use all queue iodepth and later sync requests will get long delayed. The idea is from CFQ. Signed-off-by: Shaohua Li <shaohua.li@intel.com> block: fiops add some trace information Add some trace information, which is helpful when I do debugging. Change-Id: I971fcef95e7fdb6360b0e07cffefc0b51a6fbbc0 Signed-off-by: Shaohua Li <shaohua.li@intel.com>
Change-Id: I85b1840367272d227f3df25f1d79579a317a4bf7
simple_ondemands private data must be set to NULL, otherwise we would run into a NULL pointer in kgsl_devfreq_get_dev_status(). Change-Id: Id494f1b65cb674fee56dae958bc1da267ed15501
Jana Iyengar found an interesting issue on CUBIC : The epoch is only updated/reset initially and when experiencing losses. The delta "t" of now - epoch_start can be arbitrary large after app idle as well as the bic_target. Consequentially the slope (inverse of ca->cnt) would be really large, and eventually ca->cnt would be lower-bounded in the end to 2 to have delayed-ACK slow-start behavior. This particularly shows up when slow_start_after_idle is disabled as a dangerous cwnd inflation (1.5 x RTT) after few seconds of idle time. Jana initial fix was to reset epoch_start if app limited, but Neal pointed out it would ask the CUBIC algorithm to recalculate the curve so that we again start growing steeply upward from where cwnd is now (as CUBIC does just after a loss). Ideally we'd want the cwnd growth curve to be the same shape, just shifted later in time by the amount of the idle period. Change-Id: I5a6b57d38d85c1e685835061888e719d240350dc Reported-by: Jana Iyengar <jri@google.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yuchung Cheng <ycheng@google.com> Signed-off-by: Neal Cardwell <ncardwell@google.com> Cc: Stephen Hemminger <stephen@networkplumber.org> Cc: Sangtae Ha <sangtae.ha@gmail.com> Cc: Lawrence Brakmo <lawrence@brakmo.org> Signed-off-by: David S. Miller <davem@davemloft.net>
Tracking idle time in bictcp_cwnd_event() is imprecise, as epoch_start
is normally set at ACK processing time, not at send time.
Doing a proper fix would need to add an additional state variable,
and does not seem worth the trouble, given CUBIC bug has been there
forever before Jana noticed it.
Let's simply not set epoch_start in the future, otherwise
bictcp_update() could overflow and CUBIC would again
grow cwnd too fast.
This was detected thanks to a packetdrill test Neal wrote that was flaky
before applying this fix.
Change-Id: Ifd1e4be175824a31619ff4c1dc973f82346b799d
Fixes: 30927520dbae ("tcp_cubic: better follow cubic curve after idle period")
Signed-off-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Neal Cardwell <ncardwell@google.com>
Signed-off-by: Yuchung Cheng <ycheng@google.com>
Cc: Jana Iyengar <jri@google.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Add new rmnet_data.h header file to fix compilation. Change-Id: I919c1c687eafc1dd88ae8ddf3b9a1e2b96d2a12a Signed-off-by: Muhammed Siju <msiju@codeaurora.org>
Add an entry corresponding to the MAPv4 ingress and egress data format for checksum offload. Also update the copyright. Change-Id: Id2368d621f48ebf510371acf1502efb8bead65d2 Signed-off-by: Subash Abhinov Kasiviswanathan <subashab@codeaurora.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.