At Mon, 13 May 2013 20:24:42 +0200,
Alex Riesen wrote:
>
> On Mon, May 13, 2013 at 5:53 PM, Takashi Iwai wrote:
> > At Mon, 13 May 2013 17:26:04 +0200, Takashi Iwai wrote:
> >> At Sun, 12 May 2013 11:53:41 +0200, Alex Riesen wrote:
> >> >
> >> > I just noticed (use the headphones rarely) that
On 04/12/2013 03:18 AM, Jongsung Kim wrote:
> The latest r1p5-revision of the ARM PL011 UART has 32-byte FIFOs, while all
> earlier ones have 16-byte FIFOs. This patch suggests a way to set the
> FIFO-size correctly & flexibly by using a
> function(vendor_data::get_fifosize) rather than using the
On Mon, May 13, 2013 at 5:37 AM, Zhang Yanfei wrote:
> From: Zhang Yanfei
> It seems line 119 has a potential bug there. For example,
> the kernel is loaded at physical address 511G+1008M, that is
> 0 1 11000 0
> and the kernel _end is 512G+2M, that
From: Lad, Prabhakar
This patch removes check for EPERM in dbg_g/s_register and
vidioc_g/s_register as this check is already performed by core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/pci/bt8xx/bttv-driver.c |6 --
drivers/media/pci/cx18/cx18-av-core.c |4
From: Lad, Prabhakar
This patch removes check for EPERM in vidioc_g/s_register
as this check is already performed by core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/usb/pvrusb2/pvrusb2-hdw.c |2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git
From: Lad, Prabhakar
This patch removes check for EPERM in dbg_g/s_register
as this check is already performed by core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/dvb-frontends/au8522_decoder.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git
From: Lad, Prabhakar
This patch removes check for EPERM in dbg_g/s_register of subdevice
drivers as this check is already performed by core.
Signed-off-by: Lad, Prabhakar
---
drivers/media/i2c/ad9389b.c |4
drivers/media/i2c/adv7183.c |4
From: Lad, Prabhakar
This patch series cleanups the check for EPERM in dbg_g/s_register
and vidioc_g/s_register.
Lad, Prabhakar (4):
media: i2c: remove duplicate checks for EPERM in dbg_g/s_register
media: dvb-frontends: remove duplicate checks for EPERM in
dbg_g/s_register
media:
On 05/13/2013 05:59 PM, Peter Zijlstra wrote:
> On Mon, May 13, 2013 at 05:33:12PM +0900, Chanwoo Choi wrote:
>> This patch add nr_running_cpu() function to get current
>> number of running threads of each core.
>>
> Uhm, not without a very good reason.
>
I am implementing the cpu hotplug policy
On Mon, 2013-05-13 at 12:18 +0200, Jan Kara wrote:
> On Mon 13-05-13 12:04:23, Jan Kara wrote:
> > On Fri 10-05-13 17:24:33, Cong Wang wrote:
> > > From: Cong Wang
> > >
> > > There is a hole in struct fs_quota_stat, so we have to
> > > zero the struct on stack before copying it to user-space.
>
This patch resets PCIe devices on boot to stop ongoing DMA. When
"pci=pcie_reset_endpoint_devices" is specified, a hot reset is triggered
on each PCIe root port and downstream port to reset its downstream
endpoint.
Problem:
This patch solves the problem that kdump can fail when intel_iommu=on is
On Wed, May 08, 2013 at 11:55:47AM +0300, Andy Shevchenko wrote:
> This is the rest of patch series related to ACPI DMA helpers and Lynxpoint
> DMAC.
> Patches are rebased against current Linus' tree and Vinod's branch for-linus.
>
> Since v2:
> - remove patches that are already in the Vinod's
On Tue, May 14, 2013 at 12:59:27AM +0200, Laurent Pinchart wrote:
> Hi Sascha,
>
> On Monday 13 May 2013 12:46:04 Sascha Hauer wrote:
> > On Wed, May 08, 2013 at 12:37:29PM +0200, Laurent Pinchart wrote:
> > > Hi Prabhakar,
> > >
> > > On Wednesday 08 May 2013 10:19:57 Prabhakar Lad wrote:
> > >
Hi Matt,
於 一，2013-05-13 於 20:21 +0100，Matt Fleming 提到：
> On 05/10/2013 11:29 AM, Lingzhu Xiang wrote:
> > Previously in 1fa7e69 efi_status_to_err() translated firmware status
> > EFI_NOT_FOUND to -EIO instead of -ENOENT for efivarfs operations to
> > avoid confusion. After refactoring in
On Tue, 2013-05-14 at 03:41 +0300, Ruslan Bilovol wrote:
> This was many times discussed by Russell King
> and I also was about wrong usage of IS_ERR_OR_NULL()
> in my patch. So I added this check and other people will
> be at least warned about potentially wrong usage
> of mentioned macro.
[]
>
Hi all,
Changes since 20130513:
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
Hi Mel,
On 05/13/2013 05:19 PM, Mel Gorman wrote:
For memory hot-remove case, the aio pages are pined in memory and making
the pages cannot be offlined, furthermore, the pages cannot be removed.
IIUC, you mean implement migrate_unpin() and migrate_pin() callbacks in aio
subsystem, and call
On 14 May 2013 08:00, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Fix to return -ENODEV in the dma channel request error handling
> case instead of 0, as done elsewhere in this function.
>
> Signed-off-by: Wei Yongjun
> ---
> v1 -> v2: set ret for error cases only
> ---
>
On Mon, May 13, 2013 at 8:20 PM, Yijing Wang wrote:
> On 2013/5/14 10:28, Yinghai Lu wrote:
>> We should not release resource in pci_destroy that is too early
>
> Hi Yinghai,
>"too early" means that after pci_stop_dev(), if someone else
> hold the device reference, it still care the device
On 5/9/13 11:19 AM, David Hauweele wrote:
Disabling the interrupt line could miss an IRQ and leave the line into a
low state hence locking the driver.
Have you observed this? My understanding is that the interrupt won't be
lost but instead delayed until enable_irq() is called.
I got this
2013/5/14 Neil Zhang :
> 2013/5/14 Greg Kroah-Hartman :
>> On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
>>> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
>>> into the
>>> shrinker code from within ashmem. Just bail out, avoiding a deadlock.
>>> This is
>>>
On 05/06/2013 03:55 PM, CAI Qian wrote:
[0.928031] [ cut here ]
[0.934231] kernel BUG at include/linux/gfp.h:323!
[0.940581] invalid opcode: [#1] SMP
[0.945982] Modules linked in:
[0.950048] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.9.0+ #1
[
On Mon, May 13, 2013 at 12:16:08PM +0200, Maxime Ripard wrote:
> Now that the ARM core code calls debug_ll_io_init, we can remove it from
> the machine_desc declaration.
>
> Signed-off-by: Maxime Ripard
Acked-by: Shawn Guo
> ---
> arch/arm/mach-mxs/mach-mxs.c | 1 -
> 1 file changed, 1
2013/5/14 Greg Kroah-Hartman :
> On Wed, May 01, 2013 at 09:56:13AM -0400, Robert Love wrote:
>> Don't acquire ashmem_mutex in ashmem_shrink if we've somehow recursed
>> into the
>> shrinker code from within ashmem. Just bail out, avoiding a deadlock.
>> This is
>> fine, as ashmem cache pruning is
On 5/9/13 11:19 AM, David Hauweele wrote:
The transceiver may fail under heavy traffic when a frame is transmitted
while receiving another frame.
This patch uses a mutex to separate the transmission and reception of
frames along with a secondary working queue to avoid a deadlock while
waiting
On 2013/5/14 10:28, Yinghai Lu wrote:
> We should not release resource in pci_destroy that is too early
Hi Yinghai,
"too early" means that after pci_stop_dev(), if someone else
hold the device reference, it still care the device resource ? e.g.?
Thanks!
Yijing.
> as there could be still
On 05/13/2013 05:28 PM, OGAWA Hirofumi wrote:
> Gu Zheng writes:
>
>> >From 87141ec058aad35ac55bc7c3fc2eb378566a5a6a Mon Sep 17 00:00:00 2001
>> From: Gu Zheng
>> Date: Mon, 13 May 2013 17:48:19 +0900
>> Subject: [PATCH] fs/fat: Use fat_msg() to replace printk() in
>> __fat_fs_error()
>
>> -
On 13 May 2013 19:20, Wilcox, Matthew R wrote:
> I can't apply this patch. Instead of following what it says in MAINTAINERS,
> you've sent it to my Exchange address. And now it's all mangled.
I ran the get_maintainer.pl on the patch and this is what it gave me:
scripts/get_maintainer.pl
On 05/14/2013 05:36 AM, Kevin Hilman wrote:
> Tushar Behera writes:
>
>> It updates following drivers for EXYNOS based DT platform.
>>
>> * S5M8767 driver
>> * MAX8997 driver
>> * MMC SDHCI driver
>>
>> Signed-off-by: Tushar Behera
>
> I tested this using v3.10-rc1 on Arndale, but still don't
On Mon, 2013-05-13 at 18:00 -0400, Jörn Engel wrote:
> On Mon, 13 May 2013 16:00:03 -0700, Nicholas A. Bellinger wrote:
> > On Mon, 2013-05-13 at 16:30 -0400, Joern Engel wrote:
> > > The second parameter was always 0, leading to effectively dead code. It
> > > called list_del() and
On Wed, 24 Apr 2013, Mimi Zohar wrote:
> (Reposting with expanded 'cc' list.)
>
> Included in the EVM hmac calculation is the i_mode. Any changes to
> the i_mode need to be reflected in the hmac. shmem_mknod() currently
> calls posix_acl_init(), which modifies the i_mode, after calling
On Sun, May 12, 2013 at 01:57:19PM +0200, Paul Bolle wrote:
> The Kconfig symbol EXPERIMENTAL was removed in v3.9. So this dependency
> makes it impossible to set CRYPTO_DEV_SAHARA. It's unlikely that this is
> what is intended, so let's remove this dependency.
>
> Signed-off-by: Paul Bolle
On Mon, May 06, 2013 at 01:37:13PM +0900, Jingoo Han wrote:
> The driver core clears the driver data to NULL after device_release
> or on probe failure, since commit 0998d0631001288a5974afc0b2a5f568bcdecb4d
> (device-core: Ensure drvdata = NULL when no driver is bound).
> Thus, it is not needed to
On Thu, May 02, 2013 at 02:00:38PM +0200, Laurent Navet wrote:
> Replace calls to deprecated devm_request_and_ioremap by devm_ioremap_resource.
>
> Found with coccicheck and this semantic patch:
> scripts/coccinelle/api/devm_request_and_ioremap.cocci.
>
> Signed-off-by: Laurent Navet
Patch
On Wed, May 01, 2013 at 12:52:47PM -0700, Tim Chen wrote:
> Currently the CRC-T10DIF checksum is computed using a generic table lookup
> algorithm. By switching the checksum to PCLMULQDQ based computation,
> we can speedup the computation by 8x for checksumming 512 bytes and
> even more for
On Fri, Apr 26, 2013 at 11:34:19AM +, Garg Vakul-B16394 wrote:
> Reviewed-by: Vakul Garg
Patch applied. Thanks!
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line
The patchset is started while we try to address double remove pci
devices via sysfs that is found by Gu.
main point is from Bjorn that add reference for bus, and he also
pointed out that release should be done in pci_release_device.
After reviewing the add and remove path, found more problem
Make pci_stop_dev actually detach driver only, and pci_remove_dev
device will do device_del instead. Then also could make hostbridge
to use device_unregister to be pair with device_register before.
Add is_removed to record if device_del is called already.
So mutliple calling will not cause false
We should not release resource in pci_destroy that is too early
as there could be still other use hold reference.
release them or remove it from bus devices list at last
in pci_release_dev instead.
Signed-off-by: Yinghai Lu
---
drivers/pci/probe.c | 20
Fix crash:
[ 122.181002] pci :c4:00.4: [10df:e228] type 00 class 0x02
[ 122.188541] BUG: unable to handle kernel NULL pointer dereference at
0010
[ 122.197324] IP: [] intel_iommu_add_device+0x108/0x1e0
[ 122.204753] PGD 0
[ 122.207019] Oops: [#1] SMP
[ 122.210655]
Found kernel try to load mlx4 drivers for VFs before
PF's is really loaded when the drivers are built-in, and kernel
command line include probe_vfs=63, num_vfs=63.
It turns that it also happen for hotadd path even drivers are
compiled as modules and if they loaded. Esp some VF share the
same
When sriov is enabled, VF could just start after PF in pci tree.
like c1:00.0 will be PF, and c1:00.1 and after will be VF.
acpi do have dev with same ADR. that will make them get glued
wrongly.
Skip that if it is virtfn.
Also need to set is_virtfn before pci_device_add(), as
gluing is
Gu found nested removing through
echo -n 1 > /sys/bus/pci/devices/\:10\:00.0/remove ; echo -n 1 >
/sys/bus/pci/devices/\:1a\:01.0/remove
will cause kernel crash as bus get freed.
[ 418.946462] CPU 4
[ 418.968377] Pid: 512, comm: kworker/u:2 Tainted: GW3.8.0 #2
We stop detach proc when pci_stop_device.
So should attach that during pci_bus_add_device.
Signed-off-by: Yinghai Lu
---
drivers/pci/bus.c |1 +
drivers/pci/probe.c |2 --
2 files changed, 1 insertion(+), 2 deletions(-)
Index: linux-2.6/drivers/pci/probe.c
This is the syscall slow path hooks for context tracking subsystem,
corresponding to
[PATCH] x86: Syscall hooks for userspace RCU extended QS
commit bf5a3c13b939813d28ce26c01425054c740d6731
TIF_MEMDIE is moved to the second 16-bits (with value 17), as it seems there
is no asm code using it.
Oh, sorry, my fix is incorrect !!
The return value is used by caller of caller ... it seems the user mode
can sense it !! So we still should return the correct error code to
outside when error occurs.
I think we can reference 'using compiler': it prints all errors and
warnings as far as it can,
These patches try to support context tracking for Power arch, beginning with
64-bit pSeries. The codes are ported from that of the x86_64, and in each
patch, I listed the corresponding patch for x86.
v4:
fixed some cosmetic issues suggested by Ben.
Li Zhong (5):
powerpc: Syscall hooks for
Start context tracking support from pSeries.
Signed-off-by: Li Zhong
---
arch/powerpc/platforms/pseries/Kconfig |1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc/platforms/pseries/Kconfig
b/arch/powerpc/platforms/pseries/Kconfig
index 9a0941b..023b288 100644
---
This is the exception hooks for context tracking subsystem, including
data access, program check, single step, instruction breakpoint, machine check,
alignment, fp unavailable, altivec assist, unknown exception, whose handlers
might use RCU.
This patch corresponds to
[PATCH] x86: Exception hooks
This patch corresponds to
[PATCH] x86: Use the new schedule_user API on userspace preemption
commit 0430499ce9d78691f3985962021b16bf8f8a8048
Signed-off-by: Li Zhong
---
arch/powerpc/include/asm/context_tracking.h | 10 ++
arch/powerpc/kernel/entry_64.S |3 ++-
2
This patch allows RCU usage in do_notify_resume, e.g. signal handling.
It corresponds to
[PATCH] x86: Exit RCU extended QS on notify resume
commit edf55fda35c7dc7f2d9241c3abaddaf759b457c6
Signed-off-by: Li Zhong
---
arch/powerpc/kernel/signal.c |5 +
1 file changed, 5 insertions(+)
From: Namhyung Kim
The -E/--entries option controls how many lines to be printed on stdio
output but it doesn't work as it should be:
If -E option is specified, print that many lines regardless of current
window size, if not automatically adjust number of lines printed to
fit into the window
From: Namhyung Kim
If there's no sample, kernel and exact percent output at the header
looked like "-nan%".
Signed-off-by: Namhyung Kim
---
tools/perf/util/top.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/tools/perf/util/top.c
Hi,
This patchset is a collection of 3 changes on perf top and report
tools. I wanted to make them independent, but failed due to laziness. :)
Patch 1 is a fix for -E option handling in perf top. IIUC it only
shows a given number of entries. Patch 2 is a simple fix.
Patch 3-5 remove a set of
From: Namhyung Kim
The perf report is single-threaded, so no need to grab a lock.
Although the fast path of pthread_mutex_[un]lock() is very fast,
there's ~3% gain by eliminating it when we have huge sample data.
$ perf record -a -F 10 -o perf.data.bench -- perf bench sched all
$ perf
From: Namhyung Kim
Now an user can set a default value of --percent-limit option into the
perfconfig file.
$ cat ~/.perfconfig
[report]
percent-limit = 0.1
Cc: Andi Kleen
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 7 ++-
1 file changed, 6
From: Namhyung Kim
Make the config variable also works for perf top.
Cc: Andi Kleen
Cc: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-top.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index
From: Namhyung Kim
Those _threaded() functions are needed to make hist tree handling
thread-safe, but AFAICS the only thing it does is forcing it to use
the intermediate 'collapsed' tree. It can be acheived by setting
sort__need_collapse to 1 in cmd_top() so no need to keep those
_threaded()
From: Namhyung Kim
It's a preparation patch to eliminate unneeded locking in the perf
report path.
Signed-off-by: Namhyung Kim
---
tools/perf/builtin-report.c | 26 ++
tools/perf/builtin-top.c| 3 +++
tools/perf/util/hist.c | 6 +-
3 files changed, 18
From: Namhyung Kim
The --percent-limit option is for not showing small overheaded entries
in the output.
Cc: Andi Kleen
Acked-by: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-top.txt | 4
tools/perf/builtin-top.c | 17 +++--
From: Namhyung Kim
The --percent-limit option is for not showing small overheaded entries
in the output. Maybe we want to set a certain default value like 0.1.
Cc: Andi Kleen
Acked-by: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/Documentation/perf-report.txt | 4 ++
Allocate ELF headers on page-size boundary using __get_free_pages()
instead of kmalloc().
Later patch will merge PT_NOTE entries into a single unique one and
decrease the buffer size actually used. Keep original buffer size in
variable elfcorebuf_sz_orig to kfree the buffer later and actually
This patch introduces mmap_vmcore().
Don't permit writable nor executable mapping even with mprotect()
because this mmap() is aimed at reading crash dump memory.
Non-writable mapping is also requirement of remap_pfn_range() when
mapping linear pages on non-consecutive physical pages; see
The previous patches newly added holes before each chunk of memory and
the holes need to be count in vmcore file size. There are two ways to
count file size in such a way:
1) supporse p as a poitner to the last program header entry with
PT_LOAD type, then roundup(p->p_offset + p->p_memsz,
The reasons why we don't allocate ELF note segment in the 1st kernel
(old memory) on page boundary is to keep backward compatibility for
old kernels, and that if doing so, we waste not a little memory due to
round-up operation to fit the memory to page boundary since most of
the buffers are in
Treat memory chunks referenced by PT_LOAD program header entries in
page-size boundary in vmcore_list. Formally, for each range [start,
end], we set up the corresponding vmcore object in vmcore_list to
[rounddown(start, PAGE_SIZE), roundup(end, PAGE_SIZE)].
This change affects layout of
We want to allocate ELF note segment buffer on the 2nd kernel in
vmalloc space and remap it to user-space in order to reduce the risk
that memory allocation fails on system with huge number of CPUs and so
with huge ELF note segment that exceeds 11-order block size.
Although there's already
Currently, __find_vmap_area searches for the kernel VM area starting
at a given address. This patch changes this behavior so that it
searches for the kernel VM area to which the address belongs. This
change is needed by remap_vmalloc_range_partial to be introduced in
later patch that receives any
Currently, read to /proc/vmcore is done by read_oldmem() that uses
ioremap/iounmap per a single page. For example, if memory is 1GB,
ioremap/iounmap is called (1GB / 4KB)-times, that is, 262144
times. This causes big performance degradation.
In particular, the current main user of this mmap() is
Rewrite part of read_vmcore() that reads objects in vmcore_list in the
same way as part reading ELF headers, by which some duplicated and
redundant codes are removed.
Signed-off-by: HATAYAMA Daisuke
---
fs/proc/vmcore.c | 68 --
1 files
Hello,
I keep getting on each reboot of my kernel 3.9.1 debug system:
[ 42.037225] [ cut here ]
[ 42.037237] WARNING: at lib/dma-debug.c:937 check_unmap+0x45f/0x8b0()
[ 42.037240] Hardware name: PowerEdge R710
[ 42.037243] ioatdma :00:16.0: DMA-API: device
On 2013-05-14, Matthew Garrett wrote:
> On Tue, 2013-05-14 at 01:24 +0800, Qiaowei Ren wrote:
> > static int __init txt_sysfs_init(void)
> > +{
> > + if (!tboot_enabled())
> > + return -ENODEV;
>
> If there's a CPU flag that indicates tboot support, you should add a modalias
> for
>
On 2013-05-14, Matthew Garrett wrote:
> On Tue, 2013-05-14 at 01:24 +0800, Qiaowei Ren wrote:
> > These interfaces are located
> > in /sys/devices/platform/intel_txt/config,
> > and including totally 37 files, providing access to Intel TXT
> > configuration registers.
>
> Do you have any example
On 5/14/2013 12:05 AM, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On May 14, 2013, at 12:05 AM, Nicolas Ferre wrote:
>
>> Commit 749a2b6 (net/macb: clear tx/rx completion flags in ISR)
>> introduces clear-on-write on ISR register. This behavior is not always
>> implemented when using Cadence
See the previous patch ("aio: reqs_active -> reqs_available") for why we
want to do this - this basically implements a per cpu allocator for
reqs_available that doesn't actually allocate anything.
Note that we need to increase the size of the ringbuffer we allocate,
since a single thread won't
This just converts the ioctx refcount to the new generic dynamic percpu
refcount code.
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Rusty Russell
Cc: Jens Axboe
Cc: Asai Thambi S P
Cc: Selvan Mani
Cc: Sam
This implements a refcount with similar semantics to
atomic_get()/atomic_dec_and_test() - but percpu.
It also implements two stage shutdown, as we need it to tear down the
percpu counts. Before dropping the initial refcount, you must call
percpu_ref_kill(); this puts the refcount in "shutting
From: Benjamin LaHaise
The recent changes overhauling fs/aio.c introduced a bug that results in the
kioctx not being freed when outstanding kiocbs are cancelled at exit_aio()
time. Specifically, a kiocb that is cancelled has its completion events
discarded by batch_complete_aio(), which then
This is a respin of the AIO patches that were deferred until 3.11, along
with some other stuff I had queued up.
Changes:
* Took the dynamic allocation stuff out of the percpu refcounting
patch, which Tejun was wanting. I split the dynamic bits out into
another patch, which I may resend
Originally, io_event() was documented to return the io_event if
cancellation succeeded - the io_event wouldn't be delivered via the ring
buffer like it normally would.
But this isn't what the implementation was actually doing; the only
driver implementing cancellation, the usb gadget code, never
The old aio retry infrastucture needed to save the various arguments to
to aio operations. But with the retry infrastructure gone, we can trim
struct kiocb quite a bit.
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mark Fasheh
Cc: Joel Becker
Cc:
The number of outstanding kiocbs is one of the few shared things left that
has to be touched for every kiocb - it'd be nice to make it percpu.
We can make it per cpu by treating it like an allocation problem: we have
a maximum number of kiocbs that can be outstanding (i.e. slots) - then we
just
The kiocb refcount is only needed for cancellation - to ensure a kiocb
isn't freed while a ki_cancel callback is running. But if we restrict
ki_cancel callbacks to not block (which they currently don't), we can
simply drop the refcount.
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Felipe
sock_aio_dtor() is dead code - and stuff that does need to do cleanup
can simply do it before calling aio_complete().
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Rusty Russell
Cc: Jens Axboe
Cc: Asai Thambi S P
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Felipe Balbi
Cc: Greg Kroah-Hartman
Cc: Mark Fasheh
Cc: Joel Becker
Cc: Rusty Russell
Cc: Jens Axboe
Cc: Asai Thambi S P
Cc: Selvan Mani
Cc: Sam Bradshaw
Cc: Jeff Moyer
Cc: Al Viro
Cc: Benjamin LaHaise
Reviewed-by: "Theodore Ts'o"
aio_complete() (arguably) needs to keep its own trusted copy of the tail
pointer, but io_getevents() doesn't have to use it - it's already using
the head pointer from the ring buffer.
So convert it to use the tail from the ring buffer so it touches fewer
cachelines and doesn't contend with the
Hi Mel, Benjamin, Jeff,
On 05/13/2013 11:01 PM, Benjamin LaHaise wrote:
On Mon, May 13, 2013 at 10:54:03AM -0400, Jeff Moyer wrote:
How do you propose to move the ring pages?
It's the same problem as doing a TLB shootdown: flush the old pages from
userspace's mapping, copy any existing data
When completing a kiocb, there's some fixed overhead from touching the
kioctx's ring buffer the kiocb belongs to. Some newer high end block
devices can complete multiple IOs per interrupt, much like many network
interfaces have been for some time.
This plumbs through infrastructure so we can
[asamymuth...@micron.com:
* changes for conversion to bio batch completion from Kent
* fix to apply the above changes cleanly on latest mtip32xx code
* batch bio completion changes in
* mtip_command_cleanup()
* mtip_timeout_function()
On Thu, May 09, 2013 at 05:10:26PM -0400, Dave Jones wrote:
> On Thu, May 09, 2013 at 11:02:08PM +0200, Frederic Weisbecker wrote:
>
> > > RCU options for this build are..
> > >
> > I can't reproduce that issue even with the above setting. Could you
> > please send me your whole config?
>
>
Allocates integers out of a predefined range - for use by e.g. a driver
to allocate tags for communicating with the device.
Signed-off-by: Kent Overstreet
Cc: Tejun Heo
Cc: Oleg Nesterov
Cc: Christoph Lameter
Cc: Ingo Molnar
---
include/linux/tags.h | 38
lib/Kconfig
If a bio is associated with a kiocb, allow it to be cancelled.
This is accomplished by adding a pointer to a kiocb in struct bio, and
when we go to dequeue a request we check if its bio has been cancelled -
if so, we end the request with -ECANCELED.
We don't currently try to cancel bios if IO
PM_GENERIC_DOMAINS needs PM dependency.
Fixed build warning as below:
warning: (PLAT_S3C64XX && CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has
unmet direct dependencies (PM)
warning: (PLAT_S3C64XX && CPU_EXYNOS4210) selects PM_GENERIC_DOMAINS which has
unmet direct dependencies (PM)
Previous patch got rid of kiocb->ki_users; this was done by having
kiocb_cancel()/aio_complete() explicitly synchronize with each other.
The new rule is that when a driver calls aio_complete(), after
aio_complete() returns ki_cancel cannot be running and it's safe to
dispose of kiocb->priv. But,
The way io errors are returned in the dio code was rather convoluted,
and also meant that the specific error code was lost. We need to return
the actual error so that for cancellation we can pass up -ECANCELED.
Signed-off-by: Kent Overstreet
Cc: Zach Brown
Cc: Joel Becker
Cc: Jens Axboe
Cc:
This patch does a couple things:
* Allows cancellation of any kiocb, even if the driver doesn't
implement a ki_cancel callback function. This will be used for block
layer cancellation - there, implementing a callback is problematic,
but we can implement useful cancellation by just
From: Octavian Purdila
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
This code doesn't serve any purpose anymore, since the aio retry
infrastructure has been removed.
This change should be safe because aio_read/write are also used for
synchronous IO, and called from do_sync_read()/do_sync_write() - and
there's no looping done in the sync case (the read and write
On Mon, 13 May 2013 15:42:28 +0200, Jiri Olsa wrote:
> On Mon, May 13, 2013 at 05:53:22PM +0900, Namhyung Kim wrote:
>> Hi Jiri,
>>
>> On Fri, 10 May 2013 11:04:05 +0200, Jiri Olsa wrote:
>> > On Wed, May 08, 2013 at 02:49:10PM +0900, Namhyung Kim wrote:
>> > yep, that did it.. seems I'm getting
From: Zhi Yong Wu
Register a shrinker to control the amount of memory that
is used in tracking hot regions. If we are throwing inodes
out of memory due to memory pressure, we most definitely are
going to need to reduce the amount of memory the tracking
code is using, even if it means losing
1 - 100 of 1376 matches
Mail list logo
