Re: [PATCH 00/23] per device dirty throttling -v8
On Saturday 04 August 2007, Alan Cox wrote: > > Linux has never been a "suprise your kernel interfaces all just changed > today" kernel, nor a "gosh you upgraded and didn't notice your backups > broke" kernel. > Can you give examples of backup solutions that rely on atime being updated? I can understand backup tools using mtime/ctime for incremental backups (like tar + Amanda, etc), but I'm having trouble figuring out why someone would want to use atime for that. Best regards Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Tuesday 12 April 2005 01:46, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> > I think I'm going to give a try to Neil's patch, but I'll have to apply
> > some patches from -mm.
>
> Just this one if you're using 2.6.12-rc2:
>
> --- 25/drivers/md/md.c~avoid-deadlock-in-sync_page_io-by-using-gfp_noio Mon
> Apr 11 16:55:07 2005 +++ 25-akpm/drivers/md/md.c Mon Apr 11 16:55:07 2005
> @@ -332,7 +332,7 @@ static int bi_complete(struct bio *bio,
> static int sync_page_io(struct block_device *bdev, sector_t sector, int
> size, struct page *page, int rw)
> {
> - struct bio *bio = bio_alloc(GFP_KERNEL, 1);
> + struct bio *bio = bio_alloc(GFP_NOIO, 1);
> struct completion event;
> int ret;
>
> _
Hi Andrew, all,
Sorry for the delay in reporting. This patch does indeed fix the problem.
The machine ran stress for almost 15h straight with no problems at all.
As for Nick's patch I, too, think it would be nice to be included (once the
performance problems are sorted out), since it seemed to make the block layer
more robust and well behaved (at least with stress), although I didn't run
performance tests to measure regressions.
Thanks Nick, Neil, Andrew and all others for your great help with this
issue. I'll have to put the machine on production now with the patch applied,
but let me know if I can be of any further help with these issues.
Thanks
Claudio
-
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://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Tuesday 12 April 2005 00:46, Neil Brown wrote: > On Monday April 11, [EMAIL PROTECTED] wrote: > > Neil, have you had a look at the traces? Do they mean much to you? > > Just looked. > bio_alloc_bioset seems implicated, as does sync_page_io. > > sync_page_io used to use a 'struct bio' on the stack, but Jens Axboe > change it to use bio_alloc (don't know why..) and I should have > checked the change better. > > sync_page_io can be called on the write out path, so it should use > GFP_NOIO rather than GFP_KERNEL. > > See if this helps Actually this patch is against 2.6.12-rc2-mm1 > which uses md_super_write instead of sync_page_io (which is now only > used for read). So if you are using a non-mm kernel (which seems to > be the case) you'll need to apply the patch by hand. > Hi Neil, I'll test this patch, but I'm wondering if I have to apply all the md-related patches from broken out directory of 2.6.12-rc2-mm1 or only some specific ones? Anyway I'm happy to test all those md updates, if you think they might help. Thanks Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Monday 11 April 2005 23:59, Nick Piggin wrote: > > > OK, I'll try them in a few minutes and report back. > > I'm not overly hopeful. If they fix the problem, then it's likely > that the real bug is hidden. > Well, the thing is, they do fix the problem. Or at least they hide it very well ;-) It has been running for more than 5 hours now with stress with no problems and no stuck processes. I think I'm going to give a try to Neil's patch, but I'll have to apply some patches from -mm. Thanks Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Monday 11 April 2005 13:45, Nick Piggin wrote: > > No luck yet (on SMP i386). How many disks are you using in each > raid1 array? You are using one array for swap, and one mounted as > ext3 for the working area of the `stress` program, right? > Right. I'm using two Seagate ATA133 disks (ide controler is AMD-8111) each with 4 partitions, so I get 4 md Raid1 devices. The first one, md0, is for swap. The rest are ~$ df -h FilesystemSize Used Avail Use% Mounted on /dev/md1 4.6G 1.9G 2.6G 42% / tmpfs1005M 0 1005M 0% /dev/shm /dev/md3 32G 107M 30G 1% /home /dev/md2 31G 149M 29G 1% /var In these tests, /home on md3 is the working area for stress. The io scheduler used is the anticipatory. > Neil, have you had a look at the traces? Do they mean much to you? > > Claudio - I have attached another patch you could try. It has a more > complete set of mempool and related memory allocation fixes, as well > as some other recent patches I had which reduces atomic memory usage > by the block layer. Could you try if you get time? Thanks. OK, I'll try them in a few minutes and report back. I'm curious as whether increasing the vm.min_free_kbytes sysctl value would help or not in this case. But I guess it wouldn't since there is already some free memory and also the alloc failures are order 0, right? Thanks Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Sunday 10 April 2005 03:47, Andrew Morton wrote: > > Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from > cutting in during long sysrq traces. > > Also, capture the `sysrq-m' output so we can see if the thing is out of > memory. Hi Andrew, Thanks for the tip. I booted with nmi_watchdog=0 and was able to get a full sysrq-t as well as a sysrq-m. Since it might be a little too big for the list, I've put it on a text file at: http://193.136.132.235/dl145/dump1-2.6.12-rc2.txt I also made a run with the mempool-can-fail patch from Nick Piggin. With this I got some nice memory allocation errors from the md threads when the trouble started. The dump (with sysrq-t and sysrq-m included) is at: http://193.136.132.235/dl145/dump2-2.6.12-rc2-nick1.txt Let me know if you find it more convenient to send the dumps by mail or something. Hope this helps. Thanks, Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Sunday 10 April 2005 03:53, Nick Piggin wrote: > > Looks like you may possibly have a memory allocation deadlock > (although I can't explain the NMI oops). > > I would be interested to see if the following patch is of any > help to you. > Hi Nick, I'll build a kernel with your patch and report on the results as soon as possible. Thanks Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Sunday 10 April 2005 03:47, Andrew Morton wrote: > > Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from > cutting in during long sysrq traces. > > Also, capture the `sysrq-m' output so we can see if the thing is out of > memory. OK, will do it ASAP and report back. Thanks, Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Tuesday 05 April 2005 03:12, Andrew Morton wrote:
> Claudio Martins <[EMAIL PROTECTED]> wrote:
> >While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck
> > in D state after some time.
> >This machine is a dual Opteron 248 with 2GB (ECC) on one node (the
> > other node has no RAM modules plugged in, since this board works only
> > with pairs).
> >
> >I was using stress (http://weather.ou.edu/~apw/projects/stress/) with
> > the following command line:
> >
> > stress -v -c 20 -i 12 -m 10 -d 20
> >
> >This causes a constant load avg. of around 70, makes the machine go
> > into swap a little, and writes up to about 20GB of random data to disk
> > while eating up all CPU. After about half and hour random processes like
> > top, df, etc get stuck in D state. Half of the 60 or so stress processes
> > are also in D state. The machine keeps being responsive for maybe some 15
> > minutes but then the shells just hang and sshd stops responding to
> > connections, though the machine replies to pings (I don't have console
> > acess till tomorrow).
> >
> >The system is using ext3 with md software Raid1.
> >
> > I'm interested in knowing if anyone out there with dual Opterons can
> > reproduce this or not. I also have access to an HP DL360 Dual Xeon, so I
> > will try to find out if this is AMD64 specific as soon as possible.
> > Please let me know if you want me to run some other tests or give some
> > more info to help solve this one.
>
> Can you capture the output from alt-sysrq-T?
Hi Andrew,
Due to other tasks, only now was I able to repeat the tests and capture the
the output from alt-sysrq-T. I booted with serial console, put stress to work
and when the processes started to get hung on D state I managed to capture
the following:
SysRq : Show State
sibling
task PC pid father child younger older
init D 81007fcfe0d8 0 1 0 2
(NOTLB)
810003253768 0082 81007fd19170 007d
81007fd19170 810003251470 271b 810074468e70
810003251680 8027a79a
Call Trace:{__make_request+1274}
{__down+152}
{default_wake_function+0}
{mempool_alloc+164}
{__down_failed+53}
{.text.lock.md+155}
{make_request+868}
{cache_alloc_refill+413}
{generic_make_request+545}
{autoremove_wake_function+0}
{autoremove_wake_function+0}
{submit_bio+223}
{test_set_page_writeback+203}
{swap_writepage+184}
{shrink_zone+2678}
{thread_return+0}
{thread_return+88}
{try_to_free_pages+311}
{autoremove_wake_function+0}
{__alloc_pages+533}
{__get_free_pages+14}
{__pollwait+74}
{pipe_poll+66} {do_select+725}
{__pollwait+0} {sys_select+735}
{system_call+126}
migration/0 S 810002c12720 0 2 1 3
(L-TLB)
81007ff0fea8 0046 810074806ef0 00750001
81007ff0fe58 8100032506f0 0129 810075281230
810003250900 810072ffde88
Call Trace:{migration_thread+532}
{migration_thread+0}
{kthread+217} {child_rip+8}
{kthread+0} {child_rip+0}
ksoftirqd/0 S 0 3 1 4 2
(L-TLB)
81007ff11f08 0046 810072e00430 007d
810002c194e0 810003250030 00d1 810072f3a030
810003250240
Call Trace:{__do_softirq+113}
{ksoftirqd+0}
{ksoftirqd+0} {ksoftirqd+99}
{ksoftirqd+0} {kthread+217}
{child_rip+8} {kthread+0}
{child_rip+0}
migration/1 S 810002c1a720 0 4 1 5 3
(L-TLB)
81007ff15ea8 0046 810072d1cff0 00730001
810079fe7e98 81007ff134b0 00a3 810075281230
81007ff136c0 81003381de88
Call Trace:{migration_thread+532}
{migration_thread+0}
{kthread+217} {child_rip+8}
{kthread+0} {child_rip+0}
ksoftirqd/1 S 0001 0 5 1 6 4
(L-TLB)
81007ff19f08 0046 810075376db0 0077802b8e7e
810002c114e0 81007ff12df0 01b4 810074125130
81007ff13000
Call Trace:{__do_softirq+113}
{ksoftirqd+0}
{ksoftirqd+0} {ksoftirqd+99}
{ksoftirqd+0} {kthread+217}
{child_rip+8} {kthread+0}
{child_rip+0}
events/0 S 094f2f7a804e 0 6 1 7 5
(L-TLB)
81007ff3be58 0046 0246 8013d00d
7ffe0c00 8
Processes stuck on D state on Dual Opteron
Hi, While stress testing 2.6.12-rc2 on an HP DL145 I get processes stuck in D state after some time. This machine is a dual Opteron 248 with 2GB (ECC) on one node (the other node has no RAM modules plugged in, since this board works only with pairs). I was using stress (http://weather.ou.edu/~apw/projects/stress/) with the following command line: stress -v -c 20 -i 12 -m 10 -d 20 This causes a constant load avg. of around 70, makes the machine go into swap a little, and writes up to about 20GB of random data to disk while eating up all CPU. After about half and hour random processes like top, df, etc get stuck in D state. Half of the 60 or so stress processes are also in D state. The machine keeps being responsive for maybe some 15 minutes but then the shells just hang and sshd stops responding to connections, though the machine replies to pings (I don't have console acess till tomorrow). The system is using ext3 with md software Raid1. I'm interested in knowing if anyone out there with dual Opterons can reproduce this or not. I also have access to an HP DL360 Dual Xeon, so I will try to find out if this is AMD64 specific as soon as possible. Please let me know if you want me to run some other tests or give some more info to help solve this one. Kernel config follows (compiled with gcc-3.4.4 on debian)... Best regards, thanks Claudio Martins # # Automatically generated make config: don't edit # Linux kernel version: 2.6.12-rc2 # Tue Apr 5 00:15:41 2005 # CONFIG_X86_64=y CONFIG_64BIT=y CONFIG_X86=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_X86_CMPXCHG=y CONFIG_EARLY_PRINTK=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_CLEAN_COMPILE=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_SWAP=y CONFIG_SYSVIPC=y CONFIG_POSIX_MQUEUE=y # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_SYSCTL=y # CONFIG_AUDIT is not set CONFIG_HOTPLUG=y CONFIG_KOBJECT_UEVENT=y # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set # CONFIG_EMBEDDED is not set CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_EPOLL=y CONFIG_SHMEM=y CONFIG_CC_ALIGN_FUNCTIONS=0 CONFIG_CC_ALIGN_LABELS=0 CONFIG_CC_ALIGN_LOOPS=0 CONFIG_CC_ALIGN_JUMPS=0 # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # # Loadable module support # CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_MODULE_FORCE_UNLOAD is not set CONFIG_OBSOLETE_MODPARM=y # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y CONFIG_STOP_MACHINE=y # # Processor type and features # CONFIG_MK8=y # CONFIG_MPSC is not set # CONFIG_GENERIC_CPU is not set CONFIG_X86_L1_CACHE_BYTES=64 CONFIG_X86_L1_CACHE_SHIFT=6 CONFIG_X86_TSC=y CONFIG_X86_GOOD_APIC=y # CONFIG_MICROCODE is not set CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_X86_IO_APIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_MTRR=y CONFIG_SMP=y CONFIG_PREEMPT=y CONFIG_PREEMPT_BKL=y # CONFIG_SCHED_SMT is not set CONFIG_K8_NUMA=y # CONFIG_NUMA_EMU is not set CONFIG_DISCONTIGMEM=y CONFIG_NUMA=y CONFIG_HAVE_DEC_LOCK=y CONFIG_NR_CPUS=2 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_GART_IOMMU=y CONFIG_SWIOTLB=y CONFIG_X86_MCE=y # CONFIG_X86_MCE_INTEL is not set CONFIG_SECCOMP=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y # # Power management options # CONFIG_PM=y # CONFIG_PM_DEBUG is not set # CONFIG_SOFTWARE_SUSPEND is not set # # ACPI (Advanced Configuration and Power Interface) Support # CONFIG_ACPI=y CONFIG_ACPI_BOOT=y CONFIG_ACPI_INTERPRETER=y # CONFIG_ACPI_SLEEP is not set CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y CONFIG_ACPI_BUTTON=y CONFIG_ACPI_VIDEO=y CONFIG_ACPI_FAN=y CONFIG_ACPI_PROCESSOR=y CONFIG_ACPI_THERMAL=y CONFIG_ACPI_NUMA=y # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_IBM is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 # CONFIG_ACPI_DEBUG is not set CONFIG_ACPI_BUS=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_PCI=y CONFIG_ACPI_SYSTEM=y # CONFIG_ACPI_CONTAINER is not set # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set # # Bus options (PCI etc.) # CONFIG_PCI=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y # CONFIG_UNORDERED_IO is not set # CONFIG_PCIEPORTBUS is not set CONFIG_PCI_MSI=y # CONFIG_PCI_LEGACY_PROC is not set # CONFIG_PCI_NAMES is not set # CONFIG_PCI_DEBUG is not set # # PCCARD (PCMCIA/CardBus) support # # CONFIG_PCCARD is not set # # PCI Hotplug Support # # CONFIG_HOTPLUG_PCI is not set # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=y CONFIG_IA32_EMULATION=y CONFIG_IA32_AOUT=y CONFIG_COMPAT=y CONFIG_SYSVIPC_COMPAT=y CONFIG_UID16=y # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=m # CONFIG_DEBUG_DRIVER is not set # # Memory Technology Devices (M
Re: MemShared == 0 ?
On Monday 25 June 2001 11:21, Rodrigo Ventura wrote: > /proc> cat version meminfo > Linux version 2.4.6-pre3 (yoda@damasio) (gcc version 2.95.2 19991024 > (release)) #3 Mon Jun 18 19:00:11 WEST 2001 total:used:free: > shared: buffers: cached: > Mem: 261779456 256925696 48537600 134025216 82280448 > Swap: 271425536 10993664 260431872 > MemTotal: 255644 kB \ > MemFree: 4740 kB \ > MemShared: 0 kB << What's the meaning of this? > * Buffers:130884 kB > From the discussion I've read elsewhere in this list, it means that this value is just not computed anymore and is kept at 0 for compatibility with old programs that parse this table. It seems that presenting this number was computationaly expensive for the kernel. regards cumprimentos Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: obsolete code must die
On Thursday 14 June 2001 01:44, Daniel wrote: > -- If someone really needs support for this junk, they will always have the > option of using the 2.0.x, 2.2.x or 2.4.x series. > You mean you want 2.5+ series to just stop supporting all older hardware? > So without further ado here're the features I want to get rid of: > > i386, i486 > The Pentium processor has been around since 1995. Support for these older > processors should go so we can focus on optimizations for the pentium and > better processors. > Allow me to disagree. There are still plenty of those machines around. Imagine how many of these are offering some kind of service somewhere on Internet... A 100MHz 486 is still a good machine, if your task is computing related and not "desktop" related (since most actual desktop systems are not happy with less than 64MB RAM and other features no commonly present on 486 machines ;). I have 486 at home and I intend to continue using it. > ISA bus, MCA bus, EISA bus > PCI is the defacto standard. Get rid of CONFIG_BLK_DEV_ISAPNP, > CONFIG_ISAPNP, etc > > ISA, MCA, EISA device drivers > If support for the buses is gone, there's no point in supporting devices > for these buses. > Right now I'm listening to my mp3 music in my ESS ISA sound card. If I like to listen to music while I work and I have a sound card that works why the heck do I need to buy a new PCI one? > > parallel/serial/game ports > More controversial to remove this, since they are *still* in pretty wide > use -- but USB and IEEE 1394 are the way to go. No ifs ands or buts. > Not so fast with these ones. And serial and parallel ports are sometimes very useful, especially if you deal with electronics and/or are involved in prototipe electronics and similar (although I'm trying to move to the much better USB port :) > I really think doing a clean up is worthwhile. Maybe while looking for > stuff to clean up we'll even be able to better comment the existing code. > Any other features people would like to get rid of? Any comments or > suggestions? I'd love to start a good discussion about this going so please > send me your 2 cents. > I surely agree that cleaning up old stuff is very important, but please agree that one of the strenghts of Linux is that you don't need so powerfull or so advanced hardware to do the jobs, as some commercial alternatives require, you can reuse some hardware that would be otherwise obsolete, so YOU SAVE SOME BUCKS. As a student, Radio Amateur and Electronics entusiast, many times I have to rely on old and surplus hardware since money resources are scarce. Linux lets me have fun, even with low resources. Thats the key to sucess IMO. regards Claudio - 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://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Adaptec SCSI RAID ASR-2100S
Hi I would like to know if there is any support in the 2.4.x kernels for Adaptec SCSI RAID ASR-2100S cards. It seems that one can download a driver or patch from Adaptec website for 2.2.x kernels... Can someone point me for any patch or driver available for the 2.4 series? Thanks in advance for any info. Best regards C. Martins - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
