[PATCH v6 0/5] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit

imit: cmdline > Kconfig > automatic with mtd_max_bad_blocks Jeff Westfahl (2): mtd: introduce function max_bad_blocks mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available Zach Brown (3): mtd: nand: Add max_bb_per_die and blocks_per_die fields to nand_chip mtd: nand

[PATCH v6 4/5] mtd: nand: implement 'max_bad_blocks' mtd function

Implement the new mtd function 'max_bad_blocks'. Using the chip's max_bb_per_die and blocks_per_die fields to determine the maximum bad blocks to reserve for an MTD. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> Acked-by: Bor

[PATCH v6 2/5] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available

From: Jeff Westfahl <jeff.westf...@ni.com> If the user has not set max_beb_per1024 using either the cmdline or Kconfig options for doing so, use the MTD function 'max_bad_blocks' to compute the UBI bad_peb_limit. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by

[PATCH v6 3/5] mtd: nand: Add max_bb_per_die and blocks_per_die fields to nand_chip

The fields max_bb_per_die and blocks_per_die are useful determining the number of bad blocks a MTD needs to allocate. How they are set will depend on if the chip is ONFI, JEDEC or a full-id entry in the nand_ids table. Signed-off-by: Zach Brown <zach.br...@ni.com> Acked-by: Boris Bre

[PATCH v6 1/5] mtd: introduce function max_bad_blocks

From: Jeff Westfahl <jeff.westf...@ni.com> If implemented, 'max_bad_blocks' returns the maximum number of bad blocks to reserve for a MTD. An implementation for NAND is coming soon. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com&g

[PATCH v7 1/5] mtd: introduce function max_bad_blocks

From: Jeff Westfahl <jeff.westf...@ni.com> If implemented, 'max_bad_blocks' returns the maximum number of bad blocks to reserve for a MTD. An implementation for NAND is coming soon. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com&g

[PATCH v7 2/5] mtd: ubi: use 'max_bad_blocks' to compute bad_peb_limit if available

From: Jeff Westfahl <jeff.westf...@ni.com> If the user has not set max_beb_per1024 using either the cmdline or Kconfig options for doing so, use the MTD function 'max_bad_blocks' to compute the UBI bad_peb_limit. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by

[PATCH v7 5/5] mtd: nand: set max_bb_per_die and blocks_per_die for ONFI compliant chips

ONFI compliant chips contain the values for the max_bb_per_die and blocks_per_die fields in the parameter page. When the ONFI paged is retrieved/parsed the chip's fields are set by the corresponding fields in the param page. Signed-off-by: Zach Brown <zach.br...@ni.com> Acked-by: Boris Bre

[PATCH v7 3/5] mtd: nand: Add max_bb_per_die and blocks_per_die fields to nand_chip

The fields max_bb_per_die and blocks_per_die are useful determining the number of bad blocks a MTD needs to allocate. How they are set will depend on if the chip is ONFI, JEDEC or a full-id entry in the nand_ids table. Signed-off-by: Zach Brown <zach.br...@ni.com> Acked-by: Boris Bre

[PATCH v7 4/5] mtd: nand: implement 'max_bad_blocks' mtd function

Implement the new mtd function 'max_bad_blocks'. Using the chip's max_bb_per_die and blocks_per_die fields to determine the maximum bad blocks to reserve for an MTD. Signed-off-by: Jeff Westfahl <jeff.westf...@ni.com> Signed-off-by: Zach Brown <zach.br...@ni.com> Acked-by: Bor

[PATCH v7 0/5] mtd: use ONFI bad blocks per LUN to calculate UBI bad PEB limit

cmdline > Kconfig > automatic with mtd_max_bad_blocks v7: * Moved mtd_max_bad_blocks function to be with other static inline functions so it would not look like the odd man out. Jeff Westfahl (2): mtd: introduce function max_bad_blocks mtd: ubi: use 'max_bad_blocks' to compute ba

[RESEND v1] UBI: add debugfs file for tracking PEB state

m> Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/mtd/ubi/debug.c | 151 +++- 1 file changed, 150 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/ubi/debug.c b/drivers/mtd/ubi/debug.c index f101a49..6086822 100644 --- a/drivers/mtd

[PATCH v2] UBI: add debugfs file for tracking PEB state

m> Signed-off-by: Zach Brown <zach.br...@ni.com> v2: * If ubi_io_is_bad eraseblk_count_seq_show just returns the err. * if ubi->lookuptbl returns null, its no longer treated as an error instead info for that block is not printeded * Removed check for UBI_MAX_ERASECOUNTER since it

[PATCH v3] UBI: add debugfs file for tracking PEB state

m> Signed-off-by: Zach Brown <zach.br...@ni.com> v2: * If ubi_io_is_bad eraseblk_count_seq_show just returns the err. * if ubi->lookuptbl returns null, its no longer treated as an error instead info for that block is not printeded * Removed check for UBI_MAX_ERASECOUNTER since it

[PATCH] net: phy: handle state correctly in phy_stop_machine

From: Nathan Sullivan If the PHY is halted on stop, then do not set the state to PHY_UP. This ensures the phy will be restarted later in phy_start when the machine is started again. Signed-off-by: Nathan Sullivan Signed-off-by: Brad Mouring

Re: [RESEND PATCH v3] UBI: add debugfs file for tracking PEB state

On Wed, May 17, 2017 at 12:36:35PM +0200, Honza Petrouš wrote: > 2017-05-16 20:22 GMT+02:00 Richard Weinberger <rich...@nod.at>: > > Zach, > > > > Am 16.05.2017 um 19:58 schrieb Zach Brown: > >> From: Ben Shelton <ben.shel...@ni.com> > >>

[RESEND PATCH v3] UBI: add debugfs file for tracking PEB state

m> Signed-off-by: Zach Brown <zach.br...@ni.com> --- v2: * If ubi_io_is_bad eraseblk_count_seq_show just returns the err. * if ubi->lookuptbl returns null, its no longer treated as an error instead info for that block is not printeded * Removed check for UBI_MAX_ERASECOUNTER since it

[PATCH v2] net/phy: micrel: configure intterupts after autoneg workaround

s, the phy will stall, since interrupts are off. This patch fixes the issue by calling config_intr after resetting the phy. Fixes: d2fd719bcb0e ("net/phy: micrel: Add workaround for bad autoneg ") Signed-off-by: Zach Brown <zach.br...@ni.com> --- v2: * Check phy_intterupt_is_valid

[PATCH] net/phy: micrel: configure intterupts after autoneg workaround

s, the phy will stall, since interrupts are off. This patch fixes the issue by calling config_intr after resetting the phy. Fixes: d2fd719bcb0e ("net/phy: micrel: Add workaround for bad autoneg ") Signed-off-by: Zach Brown <zach.br...@ni.com> --- drivers/net/phy/micrel.c | 2 ++ 1

Re: PATCH: maestro ported to 2.4 PCI API

> - ported to Linux 2.4 PCI API, PCI module based, cleaned up > return values. (taking into account all the hints Jeff has given > me ;) cool :) > - did NOT change any power management support, since I don't know > anything about power management. someone

Re: PATCH: maestro ported to 2.4 PCI API

> Its useful to have version ids. So it would be better people used them more I wasn't sure, so am happy leaving them in as well :) I suppose they're an easier way to sync dmesg with code version than knowing what is in which kernel version. -- zach - To unsubscribe from this list: send the

Re: [PATCH] maestro3 oops + fix (for ac9!)

> D'oh, looks like if power management is disabled, pmdev is NULL (I get > that message when I load the module), but we try to derefence it anyways. > The fix is obvious: duh, yeah, I'll send out a proper patch that handles the pm_register failure too. thanks. -- zach - To unsubscribe from

Re: [Fwd: [Fwd: Is sendfile all that sexy? (fwd)]]

On Thu, Jan 18, 2001 at 08:49:38AM -0800, Linus Torvalds wrote: > That has its advantages: it's a very local thing, and doesn't need any > state. However, the fact is that you _need_ the persistency of a socket > option if you want to take advantage of external programs etc getting good >

Re: Possible Bug: drivers/sound/maestro.c

> > have this problem (or a similar one, anyway -- sometimes the sound becomes > > distorted or comes only through one speaker) under both Linux 2.2 and > > Win2K. If it was just Linux, I'd assume it was a driver problem, but the This is a long-standing bug with the maestro2 driver. My

[PATCH] maestro3 PM update

@@ -28,6 +28,9 @@ * Shouts go out to Mike "DJ XPCom" Ang. * * History + * v1.20 - Jan 30 2001 - Zach Brown <[EMAIL PROTECTED]> + * get rid of pm callback and use pci_dev suspend/resume instead + * m3_probe cleanups, including pm oops think-o * v1.10 - Jan 6 2001 - Za

[PATCH] maestro3 2.4.4-pre5 fixes

The maestro3 driver has a error cleanup bug that would leave its reboot notifier registerd after exiting init_module with an error. Bayad. It also had a minor bug where it didn't explicitly set the codec->id before probing.. this patch vs 2.4.4-pre5 (I hope, its really vs jeff's cvs :)) fixes

Re: X15 alpha release: as fast as TUX but in user space

> i think Zach's phhttpd is an important milestone as well, it's the first > userspace webserver that shows how to use event-based, sigio-based async > networking IO and sendfile() under Linux. (I believe it had some *blush* > performance problems related to sigio queue overflow, these issues

Re: Patch to make ymfpci legacy address 16 bits

On Wed, May 09, 2001 at 05:08:15PM -0400, Jeff Garzik wrote: > Why does maestro.c not use my suggestion? Because it doesn't use struct > pci_driver. I finally found an able hacker with maestro hardware with power management. He not only fixed the nasty pm races that were causing channel

[PATCH] maestro3 2.4.2 pci dma address fix

/drivers/sound/maestro3.c.dmaWed Feb 28 09:22:18 2001 +++ linux-2.4.2/drivers/sound/maestro3.cWed Feb 28 10:10:07 2001 @@ -28,6 +28,9 @@ * Shouts go out to Mike "DJ XPCom" Ang. * * History + * v1.22 - Feb 28 2001 - Zach Brown <[EMAIL PROTECTED]> + * allocate mem

[RFC] pci_dma_set_mask()

This patch really has two parts. Most of it adds a helper function that does the if(pci_dma_supported()) { ->dma_mask = mask } code path. I was using the api today and didn't realize that I had to set the mask myself, I assumed the _supported call would do it. If people prefer the

Re: [RFC] pci_dma_set_mask()

> pci_dma_supported has a boolean return, but the kernel norm is to return > zero on success, and -EFOO on error. I like your proposal with the *nod* I just followed pci_dma_supported(). > extremely minor nit that I think pci_set_dma_mask should return ENODEV > or EIO or something on error,

Re: [RFC] pci_dma_set_mask()

On Wed, Feb 28, 2001 at 03:23:53PM -0800, David S. Miller wrote: > Jeff/Zach, I agree, I'm fully for such a patch, but please update the > documentation! It is the most important part of the patch. Very good point. I'll add Jeff's error returning and spin some minor docs and resend. thanks.

[RFC] pci_set_dma_mask() + doc :)

please feel free to flame or apply, I'm not sure I'm really fond of the code example.. - z --- linux-2.4.2/include/linux/pci.h.dmasup Wed Feb 28 10:26:14 2001 +++ linux-2.4.2/include/linux/pci.h Wed Feb 28 10:30:12 2001 @@ -527,6 +527,7 @@ int pci_enable_device(struct pci_dev *dev);

[CFT] maestro update vs 2.2.18

I finally spent some time fixing up the maestro driver. lots of feature additions had backed up, and the source was rotting. Its still gross, but at least its cleaned up a bit. "It works for me" on my pentium with an ESS maestro2 engineering board, but laptops will be another story entirely.

Re: IDE UDMA on a CMD-648 Chip

> I can't find the chip's datasheet. CMD only gives it to direct customers. > I do have the datasheet for the CMD-646U, a prior UDMA supporting chip. Have you tried mailing them?. I sent mail to something silly like support@cmd. After they found the right person for me to talk to, I mentioned

Re: user space web server accelerator support

> Fantastic! > > I was not aware of it, sorry... where can I find some doc? There are some patches in the apache source rpms in http://www.zabbo.net/phhttpd/ that shows how apache can connect to another daemon and get its incoming connections sockets from it. phhttpd itself is pretty hairy

Re: [patch] ess maestro, support for hardware volume control

> this patch applies to (at least) 2.4.3 up to and including 2.4.6-pre2. > It enables the hardware volume control feature of the maestro. cool. I had support for this in the mega-patch I posted long ago, but I never seperated and submitted those changes 'cause I'm a moron. > By giving hwv=0 to

Re: [patch] ess maestro, support for hardware volume control

> below is the version with the suggested fixes, and with s/hwv/hwvol/ for > hwv_input also. fantastic, thanks lukas. alan, can you throw this in -ac? I don't think it will cause problems for people with nonstandard wiring on the hw vol pins (read: dell lattitudes), but if it does we can

Re: [patch] ess maestro, support for hardware volume control

> I now have a patch that will output the hwv buttons pressed (up, > down, mute) to a new dynamically allocated misc device as letters > u, d, m, instead of directly modifying the mixer. Anyone want > that? It's more flexible than either the patch that's currently > in -ac or Lukas's patch, but

[RFC][PATCH] cutting up struct kernel_stat into cpu_stat

The attached patch-in-progress removes the per-cpu statistics from struct kernel_stat and puts them in a cpu_stat structure, one per cpu, cacheline padded. The data is still coolated and presented through /proc/stat, but another file /proc/cpustat is also added. The locking is as nonexistant as

[RFC][PATCH] struct kernel_stat -> struct cpu_stat[NR_CPUS]

Currently struct kernel_stat has a few pre cpu arrays. This creates cacheline exchange noise as the cpus update their entries in each array. This patch creates an array of per cpu structs. The structure is padded to the length of a cacheline. The meat of the patch against 2.4.6-pre8 is

[PATCH] 2.4.7-pre3 kernel_stat -> cpu_stat[NR_CPUS]

This patch does the following: - creates a cacheline aligned/padded struct cpu_stat[NR_CPUS]. - moves the [NR_CPUS] members of kernel_stat into cpu_stat This moves the stat data that a cpu will update into a contiguous region. Previous users of kernel_stat would compete for an array's

Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface

> Unrelated to your change: the maestro reboot notifier shouldn't need to > unregister all that stuff. Who cares if the sound devices are freed, > since we are rebooting. free_irq+maestro_power seems sufficient. or > maybe stop_dma+free_irq+poweroff. its only the power stuff that matters.

Re: Patch: linux-2.4.0-test11/drivers/sound/maestro.c port to new PCI interface

they're all under one big lock. > As far as I can tell, I agree with you, but I do not think > that is related to the move to the new PCI interface. *nod* > I also agree that the ioctl patch is kind of a bandaid over > the problems that you described, and, while Zach Brow

Re: sunhme.c patch for new PCI interface (UNTESTED)

On Thu, Nov 16, 2000 at 04:22:36AM -0800, David S. Miller wrote: > Sure, that sounds nice. > > Actually, one of the possible "grand plans" for 2.5 is a unified > "struct device". I don't know what will actually happen here. apologies for pointing out the potentially obvoius, but people might

Maestro3/Allegro: (was ESS device "1998")

On Thu, Nov 02, 2000 at 12:03:41PM +, Mo McKinlay wrote: > I recently obtained an HP Omnibook XE2 laptop. It's a reasonably As people have mentioned, there is an alpha free driver near http://www.zabbo.net/maestro3/. Its not quite up to par yet. maybe the web page should talk a bit more

maestro3 2.2 oss driver snapshot

http://www.zabbo.net/maestro3/ contains a driver for the maestro3 and allegro chipsets that I'm fairly happy with. its 2.2 only for now, play with 2.4 at your own risk. for now it includes its own ac97_codec.c that is backported from 2.2. I expect playback to work as well as ac97 mixing. apm

maestro3 patch, resent

duh. I sent this to rutgers originally.. --- Date: Mon, 5 Feb 2001 07:42:25 -0500 From: Zach Brown <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: [PATCH] maestro3 2.4.1-ac2 shutdown fix Its a wonder that anyone lets me write code. The following fixes a goofy shutdown p

Re: [PATCH] maestro3 still oopses?

* v1.21 - Feb 04 2001 - Zach Brown <[EMAIL PROTECTED]> + * fix up really dumb notifier -> suspend oops * v1.20 - Jan 30 2001 - Zach Brown <[EMAIL PROTECTED]> * get rid of pm callback and use pci_dev suspend/resume instead * m3_probe cleanups, including pm oops think-o @@

Re: user space web server accelerator support

> Zach, have you ever noticed such a performance bottleneck in your phhttpd? yup, this is definitely something you don't want to be doing in the fast path :) > Any thoughts? Sorry I don't remember the start of this thread, but I'll ask anyway; have you looked at Ingo Molnar's Tux server? Its

Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration

Arjan van de Ven wrote: > On Sun, 2005-04-03 at 12:57 -0700, Joel Becker wrote: > >>Folks, >> I humbly submit configfs. With configfs, a configfs >>config_item is created via an explicit userspace operation: mkdir(2). >>It is destroyed via rmdir(2). The attributes appear at mkdir(2) time,

Re: [PATCH] configfs, a filesystem for userspace-driven kernel object configuration

Matt Mackall wrote: > On Sun, Apr 03, 2005 at 12:57:28PM -0700, Joel Becker wrote: > >> An interface in /proc where the API is: >>or an ioctl(2) interface where the API is: >> >>becomes this in configfs: >> >> # cd /config/mythingy >> # mkdir foo >> # echo 1 > foo/index >>

Re: [Patch] invalidate range of pages after direct IO write

>> But this won't happen if next >>started as 0 and we didn't update it. I don't know if retrying is the >>intended behaviour or if we care that the start == 0 case doesn't do it. > > > Good point. Let's make it explicit? Looks great. I briefly had visions of some bitfield to pack the three

[Patch] write and wait on range before direct io read

This adds filemap_write_and_wait_range(mapping, lstart, lend) which starts writeback and waits on a range of pages. We call this from __blkdev_direct_IO with just the range that is going to be read by the direct_IO read. It was lightly tested with fsx and ext3 and passed. Signed-off-by: Zach

[Patch] only unmap what intersects a direct_IO op

Now that we're only invalidating the pages that intersected a direct IO write we might as well only unmap the intersecting bytes as well. This passed a light fsx load with page cache, direct, and mmap IO. Signed-off-by: Zach Brown <[EMAIL PROTECTED]> --- filemap.c | 12 -

__getblk() spinning when size != bdev->...i_blkbits

Recently I debugged something that was spinning in the for(;;) in __getblk_slow(). It turned out it was calling __getblk() with a size argument that didn't match the bdev's inode's i_blkbits. grow_buffers() would add a page at the index calculated from the 4k size argument but when

[Patch] invalidate range of pages after direct IO write

in and out: 0m28.029s 0m20.093s 0m3.166s 16673 125107 0m27.949s 0m20.068s 0m3.227s 18426 126094 and after the patch: 0m26.775s 0m19.996s 0m3.060s 3505 124982 0m26.856s 0m19.935s 0m3.052s 3505 125279 Signed-off-by: Zach Brown <[EMAIL PROTECTED]> --- include/linux/fs.h |2 ++ mm/fil

Re: [Patch] invalidate range of pages after direct IO write

Andrew Morton wrote: > Note that the same optimisation should be made in the call to > unmap_mapping_range() in generic_file_direct_IO(). Currently we try and > unmap the whole file, even if we're only writing a single byte. Given that > you're now calculating iov_length() in there we might as

Re: [Patch] invalidate range of pages after direct IO write

Andrew Morton wrote: > I'd be inclined to hold off on the macro until we actually get the > open-coded stuff right.. Sometimes the page lookup loops take an end+1 > argument and sometimes they take an inclusive `end'. I think. That might > make it a bit messy. > > How's this look? Looks

Re: [PATCH] 6700/6702PXH quirk

Jeff Garzik wrote: > > > FWIW, compilers generate AWFUL code for bitfields. Bitfields are > really tough to do optimally, whereas bit flags ["unsigned int flags & > bitmask"] are the familiar ints and longs that the compiler is well > tuned to optimize. I wouldn't have chosen the

Re: [PATCH] 6700/6702PXH quirk

> You can hide the "complexity" of the second line behind > macros. And this is what is done in most places. oh, I agree. My only point is that if the *only* argument against bitfields is that they're inefficient (insert vague hand-waving) then people will happily decide to live with that

Re: GFS

Pekka J Enberg wrote: > Sorry if this is an obvious question but what prevents another thread > from doing mmap() before we do the second walk and messing up num_gh? Nothing, I suspect. OCFS2 has a problem like this, too. It wants a way for a file system to serialize mmap/munmap/mremap during

Re: GFS

Pekka Enberg wrote: > In addition, the vma walk will become an unmaintainable mess as soon > as someone introduces another mmap() capable fs that needs similar > locking. Yup, I suspect that if the core kernel ends up caring about this problem then the VFS will be involved in helping file

Re: GFS

> What I meant was that, if a filesystem requires vma walks, we need to do > it VFS level with something like the following patch. I don't think this patch is the way to go at all. It imposes an allocation and vma walking overhead for the vast majority of IOs that aren't interested. It

Re: GFS

> That doesn't matter. Please don't put in any effort for lustre special > cases - they are unwilling to cooperate and they'll get what they deserve. Sure, we can add that extra functional layer in another pass. I thought I'd still bring it up, though, as OCFS2 is slated to care at some point

Re: [patch] remove redundant iov segment check

I wonder if it wouldn't be better to make this change as part of a larger change that moves towards an explicit iovec container struct rather than bare 'struct iov *' and 'nr_segs' arguments. I suspect it should be rather trivial to get this started. As a first step we simply add a struct

setting task->ioprio from a kernel thread

In OCFS2 there is currently an in-kernel heartbeat thread that really wants to communicate liveness to other nodes as quickly as possible by writing to a block device. Setting aside the specific wisdom of a kernel heartbeat thread for a bit, has it been considered that kernel threads might

Re: [2.6 patch] schedule obsolete OSS drivers for removal

Adrian Bunk wrote: > This patch schedules obsolete OSS drivers (with ALSA drivers that > support the same hardware) for removal. > I've Cc'ed the people listed in MAINTAINERS as being responsible for one > or more of these drivers, and I've also Cc'ed the ALSA people. I haven't touched the

Re: [patch] aio: add per task aio wait event condition

On Dec 29, 2006, at 6:31 PM, Chen, Kenneth W wrote: The AIO wake-up notification from aio_complete is really inefficient in current AIO implementation in the presence of process waiting in io_getevents(). Yeah, it's a real deficiency. Thanks for taking a stab at it. This patch adds a wait

Re: [patch] aio: streamline read events after woken up

Given the previous patch "aio: add per task aio wait event condition" that we properly wake up event waiting process knowing that we have enough events to reap, it's just plain waste of time to insert itself into a wait queue, and then immediately remove itself from the wait queue for *every*

Re: [patch] aio: remove spurious ring head index modulo info->nr

This makes the modulo of ring->head into local variable head unnecessary. This patch removes that bogus code. Looks fine to me: Acked-by: Zach Brown <[EMAIL PROTECTED]> - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message

Re: [patch] aio: make aio_ring_info->nr_pages an unsigned int

--- ./include/linux/aio.h.orig 2006-12-24 22:31:55.0 -0800 +++ ./include/linux/aio.h 2006-12-24 22:41:28.0 -0800 @@ -165,7 +165,7 @@ struct aio_ring_info { struct page **ring_pages; spinlock_t ring_lock; - long

Re: [patch] aio: add per task aio wait event condition

That is not possible because when multiple tasks waiting for events, they enter the wait queue in FIFO order, prepare_to_wait_exclusive() does __add_wait_queue_tail(). So first io_getevents() with min_nr of 2 will be woken up when 2 ops completes. So switch the order of the two sleepers

Re: [patch] aio: make aio_ring_info->nr_pages an unsigned int

I had that changes earlier, but dropped it to make the patch smaller. Still have it kicking around? Making this stuff more consistent would be nice, I agree, I'm just not sure it's worth the risk of running into some subtle bugs. - z - To unsubscribe from this list: send the line

Re: [RFC] Heads up on a series of AIO patchsets

ues). The IO_CMD_EPOLL_WAIT patch (originally from Zach Brown with modifications from Jeff Moyer and me) addresses this problem for native linux aio in a simple manner. It's simple looking, sure. This current flipping didn't even occur to me while throwing the patch toget

Re: [patch] aio: add per task aio wait event condition

On Jan 2, 2007, at 5:50 PM, Chen, Kenneth W wrote: Zach Brown wrote on Tuesday, January 02, 2007 5:24 PM That is not possible because when multiple tasks waiting for events, they enter the wait queue in FIFO order, prepare_to_wait_exclusive() does __add_wait_queue_tail(). So first

Re: [patch] aio: streamline read events after woken up

buffer index there. By then, most of you would probably veto the patch anyway ;-) haha, touche :) I still think it'd be the right thing, though. We can let the patch speak for itself :). - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a

Re: [patch] aio: add per task aio wait event condition

On Jan 2, 2007, at 10:36 PM, Chen, Kenneth W wrote: Zach Brown wrote on Tuesday, January 02, 2007 6:06 PM In the example you gave earlier, task with min_nr of 2 will be woken up after 4 completed events. I only gave 2 ios/events in that example. Does that clear up the confusion

Re: [RFC] Heads up on a series of AIO patchsets

generic_write_checks() are done in the submission path, not repeated during retries, so such types of checks are not intended to run in the aio thread. Ah, I see, I was missing the short-cut which avoids re-running parts of the write path if we're in a retry. if

Re: [PATCH -mm 1/5][AIO] - Rework compat_sys_io_submit

On Nov 29, 2006, at 2:32 AM, Sébastien Dugué wrote: compat_sys_io_submit() cleanup Cleanup compat_sys_io_submit by duplicating some of the native syscall logic in the compat layer and directly calling io_submit_one() instead of fooling the syscall into thinking it is

Re: [PATCH -mm 1/5][AIO] - Rework compat_sys_io_submit

sys_io_getevents() reads: uh! ^you must be meaning sys_io_submit()? Heh, yes, of course. Damn these fingers! - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

Re: [rfc patch] optimize o_direct on block device

At that time, a patch was written for raw device to demonstrate that large performance head room is achievable (at ~20% speedup for micro- benchmark and ~2% for db transaction processing benchmark) with a tight I/O submission processing loop. Where exactly does the benefit come from? icache

Re: [rfc patch] optimize o_direct on block device

On Nov 30, 2006, at 10:16 PM, Chen, Kenneth W wrote: Zach Brown wrote on Thursday, November 30, 2006 1:45 PM At that time, a patch was written for raw device to demonstrate that large performance head room is achievable (at ~20% speedup for micro- benchmark and ~2% for db transaction

Re: [patch] remove redundant iov segment check

On Dec 4, 2006, at 8:26 AM, Chen, Kenneth W wrote: The access_ok() and negative length check on each iov segment in function generic_file_aio_read/write are redundant. They are all already checked before calling down to these low level generic functions. ... So it's not possible to

Re: [patch] remove redundant iov segment check

> Maybe we should create another internal generic_file_aio_read/write > for in-core function? fs/read_write.c and fs/aio.c are not module-able > and the check is already there. For external module, we can do the > check and then calls down to the internal one. Maybe. I'd rather see fewer

Re: [patch] kill pointless ki_nbytes assignment in aio_setup_single_vector

t; Signed-off-by: Ken Chen <[EMAIL PROTECTED]> That seems to be the case, indeed. Acked-by: Zach Brown <[EMAIL PROTECTED]> - z - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http:/

Re: [patch] optimize o_direct on block device - v3

(my monkey test code is on http://kernel-perf.sourceforge.net/ diotest). Nice. Do you have any interest in working with the autotest ( http:// test.kernel.org/autotest ) guys to get your tests into their rotation? - z - To unsubscribe from this list: send the line "unsubscribe

[RFC] tracepipe -- event streams, debugfs, and pipe_buffers

This quick tracepipe patch is an attempt to make it trivial for a developer to generate debugging traces in the kernel and get them to mass storage without having the tracing enormously skew behaviour. It is built off of Greg's debugfs and Linus' advocacy of efficient buffer transit with pipes

Re: [RFC] tracepipe -- event streams, debugfs, and pipe_buffers

Karim Yaghmour wrote: > Zach Brown wrote: > >>Thoughts? I, for one, am tired of writing throw-away per-cpu tracing >>patches ;) > > Have you taken a look at relayfs and ltt? Only briefly. They've always seemed more involved than the sort of thing I was after

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

Plus there's the fundamental killer that KAIO is a /lot/ harder to implement (and to maintain) on the kernel side: it has to be implemented for every IO discipline, and even for the IO disciplines it supports at the moment, it is not truly asynchronous for things like metadata blocking or

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

The more I think about it, a reasonable solution might actually be to use threadlets for disk I/O and pure event based processing for networking. It is two different handling paths and non-unified, but that might be the price for good performance :-) I generally agree, with some comments. If

Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3

direct-io.c is evil. Ridiculously. You will have a hard time finding someone to defend it, I predict :). There is good news on that front, too. Chris (Mason) is making progress on getting rid of the worst of the Magical Locking that makes buffered races with O_DIRECT ops so awful. I'm

Re: [rfc][patch] dynamic resizing dentry hash using RCU

On Feb 23, 2007, at 7:37 AM, Nick Piggin wrote: The dentry hash uses up 8MB for 1 million entries on my 4GB system is one of the biggest wasters of memory for me. Because I rarely have more than one or two hundred thousand dentries. And that's with several kernel trees worth of entries.

Re: [PATCH 1/3] aio: fix oops because of extra IO control block freeing.

On Mar 7, 2007, at 2:14 PM, Andrew Morton wrote: On Mon, 05 Mar 2007 17:23:33 +0300 Leonid Ananiev <[EMAIL PROTECTED]> wrote: From Leonid Ananiev The patch fixes oops because of extra IO control block freeing. IO is retried if page could not be invalidated. This patch is incorrect and

[PATCH] dio: invalidate clean pages before dio write

use invalidation to fail, panicing the box. The test can be found in the 'aio_dio_bugs' test group in test.kernel.org/autotest. After this patch the test passes. Signed-off-by: Zach Brown <[EMAIL PROTECTED]> --- mm/filemap.c | 48 1 file ch

Re: Vectored AIO breakage for sockets and pipes ?

I'm not sure what the best way to fix this is. One option is to always make a copy of the iovec and pass that down. Any other thoughts ? Can we use this as another motivation to introduce an iovec container struct instead of passing a raw iov/seg? The transition could turn hand-rolled

Re: [patch 00/11] ANNOUNCE: "Syslets", generic asynchronous system call support

I'm finally back from my travel and conference hiatus.. you guys have been busy! :) On Feb 13, 2007, at 6:20 AM, Ingo Molnar wrote: I'm pleased to announce the first release of the "Syslet" kernel feature and kernel subsystem, which provides generic asynchrous system call support:

Re: [patch 05/11] syslets: core code

But the whole point is that the notion of a "register" is wrong in the first place. [...] forget about it then. The thing we "register" is dead-simple: struct async_head_user { struct syslet_uatom __user **completion_ring; unsigned long

Re: [patch 05/14] syslets: core code

+static void +__mark_async_thread_ready(struct async_thread *at, struct async_head *ah) +{ + list_del(>entry); + list_add_tail(>entry, >ready_async_threads); +__mark_async_thread_busy(struct async_thread *at, struct async_head *ah) +{ + list_del(>entry); +

Re: [PATCH] aio: fix kernel bug when page is temporally busy

If invalidate_inode_pages2_range() will return EIOCBRETRY as the patch "aio: fix kernel bug when page is temporally busy" Sorry Leonid, this patch is not safe. It returns -EIOCBRETRY without guaranteeing that kick_iocb() will be called. This can lead to operations hanging, both AIO and

<    1   2   3   4   5   6   7   8   9   10   >