Re: ORACLE and 2.4-test10
Frank, You must be looking at Oracle 8.0 docs. If you are looking to update a production system we only support stable kernels. Pre kernels are not yet really stable and therefore not supported. (We had to draw the line somewhere.) That said, we will look into O_DIRECT and kiovects. We may be able to do some performance testing on that. Regards, Frank van Maarseveen wrote: > On Fri, Nov 17, 2000 at 06:14:14PM +, Alan Cox wrote: > > SHM is resolved but O_SYNC is not yet fixed. You could therefore easily lose > > your entire database > > I assume 2.2.18-pre-latest is ok? > Some oracle doc still refers to 2.0.34 > > -- > Frank > - > 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/ -- ======= Josue Emmanuel Amaro [EMAIL PROTECTED] Linux Products Manager Phone: 650.506.1239 Intel and Linux Technologies Group Fax: 650.413.0167 === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-413-0167 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Intel and Linux Technologies version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Manager - Linux adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
Re: [patch] O_SYNC patch 3/3, add inode dirty buffer list support to ext2
n bh;
> > }
> > @@ -907,7 +907,7 @@
> > if (partial == chain)
> > mark_inode_dirty(inode);
> > else
> > - mark_buffer_dirty(partial->bh);
> > + mark_buffer_dirty_inode(partial->bh, inode);
> > ext2_free_branches(inode, &nr, &nr+1, (chain+n-1) - partial);
> > }
> > /* Clear the ends of indirect blocks on the shared branch */
> > @@ -916,7 +916,7 @@
> > partial->p + 1,
> > (u32*)partial->bh->b_data + addr_per_block,
> > (chain+n-1) - partial);
> > - mark_buffer_dirty(partial->bh);
> > + mark_buffer_dirty_inode(partial->bh, inode);
> > if (IS_SYNC(inode)) {
> > ll_rw_block (WRITE, 1, &partial->bh);
> > wait_on_buffer (partial->bh);
> > @@ -1208,7 +1208,7 @@
> > raw_inode->i_block[0] = cpu_to_le32(kdev_t_to_nr(inode->i_rdev));
> > else for (block = 0; block < EXT2_N_BLOCKS; block++)
> > raw_inode->i_block[block] = inode->u.ext2_i.i_data[block];
> > - mark_buffer_dirty(bh);
> > + mark_buffer_dirty_inode(bh, inode);
> > if (do_sync) {
> > ll_rw_block (WRITE, 1, &bh);
> > wait_on_buffer (bh);
> > --- linux-2.4.0-test11/fs/ext2/namei.c.~1~Tue Nov 21 15:40:22 2000
> > +++ linux-2.4.0-test11/fs/ext2/namei.cTue Nov 21 16:01:15 2000
> > @@ -296,7 +296,7 @@
> > dir->u.ext2_i.i_flags &= ~EXT2_BTREE_FL;
> > mark_inode_dirty(dir);
> > dir->i_version = ++event;
> > - mark_buffer_dirty(bh);
> > + mark_buffer_dirty_inode(bh, dir);
> > if (IS_SYNC(dir)) {
> > ll_rw_block (WRITE, 1, &bh);
> > wait_on_buffer (bh);
> > @@ -337,7 +337,7 @@
> > else
> > de->inode = 0;
> > dir->i_version = ++event;
> > - mark_buffer_dirty(bh);
> > + mark_buffer_dirty_inode(bh, dir);
> > if (IS_SYNC(dir)) {
> > ll_rw_block (WRITE, 1, &bh);
> > wait_on_buffer (bh);
> > @@ -449,7 +449,7 @@
> > strcpy (de->name, "..");
> > ext2_set_de_type(dir->i_sb, de, S_IFDIR);
> > inode->i_nlink = 2;
> > - mark_buffer_dirty(dir_block);
> > + mark_buffer_dirty_inode(dir_block, dir);
> > brelse (dir_block);
> > inode->i_mode = S_IFDIR | mode;
> > if (dir->i_mode & S_ISGID)
> > @@ -755,7 +755,7 @@
> > EXT2_FEATURE_INCOMPAT_FILETYPE))
> > new_de->file_type = old_de->file_type;
> > new_dir->i_version = ++event;
> > - mark_buffer_dirty(new_bh);
> > + mark_buffer_dirty_inode(new_bh, new_dir);
> > if (IS_SYNC(new_dir)) {
> > ll_rw_block (WRITE, 1, &new_bh);
> > wait_on_buffer (new_bh);
> > @@ -786,7 +786,7 @@
> > mark_inode_dirty(old_dir);
> > if (dir_bh) {
> > PARENT_INO(dir_bh->b_data) = le32_to_cpu(new_dir->i_ino);
> > - mark_buffer_dirty(dir_bh);
> > + mark_buffer_dirty_inode(dir_bh, old_inode);
> > old_dir->i_nlink--;
> > mark_inode_dirty(old_dir);
> > if (new_inode) {
> > --- linux-2.4.0-test11/include/linux/ext2_fs.h.~1~Tue Nov 21 15:40:22 2000
> > +++ linux-2.4.0-test11/include/linux/ext2_fs.hTue Nov 21 16:01:15 2000
> > @@ -549,6 +549,7 @@
> >
> > /* fsync.c */
> > extern int ext2_sync_file (struct file *, struct dentry *, int);
> > +extern int ext2_fsync_inode (struct inode *, int);
> >
> > /* ialloc.c */
> > extern struct inode * ext2_new_inode (const struct inode *, int, int *);
> > --- linux-2.4.0-test11/mm/filemap.c.~1~ Tue Nov 21 15:47:48 2000
> > +++ linux-2.4.0-test11/mm/filemap.c Tue Nov 21 16:01:15 2000
> > @@ -2521,8 +2521,14 @@
> > if (cached_page)
> > page_cache_free(cached_page);
> >
> > + /* For now, when the user asks for O_SYNC, we'll actually
> > + * provide O_DSYNC. */
> > + if ((status >= 0) && (file->f_flags & O_SYNC))
> > + status = generic_osync_inode(inode, 1); /* 1 means datasync */
> > +
> > err = written ? written : status;
> > out:
> > +
> > up(&inode->i_sem);
> > return err;
> > fail_write:
> > -
> > 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/
> -
> 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/
--
===
Josue Emmanuel Amaro [EMAIL PROTECTED]
Linux Products Manager Phone: 650.506.1239
Intel and Linux Technologies Group Fax: 650.413.0167
===
begin:vcard
n:Amaro;Josue Emmanuel
tel;cell:650-245-5131
tel;fax:650-413-0167
tel;work:650-506-1239
x-mozilla-html:FALSE
url:http://www.oracle.com
org:Intel and Linux Technologies
version:2.1
email;internet:[EMAIL PROTECTED]
title:Sr.Product Manager - Linux
adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States
fn:Josue Emmanuel Amaro
end:vcard
Bug with EtherExpress on 2.4.0 test 7
All, We have been doing some testing with 2.4 and we are running into problems with the EtherExpress Driver. Symptoms: On some reboots it reports eth0 is out of resources. Also during heavy loads it will report being out of resources and the system drops of the network. The warning is printed on the status check at line 1576 of drivers/net/eepro100.c (linux-2.4.0-test7). We changed to a tulip based network card and have not been able to reproduce the problem. Let me know if additional information is needed, -- === Josue Emmanuel Amaro Linux Products Manager Oracle Corporation === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-506-7369 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Linux Strategic Business Unit version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Line Manager adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS 1op7;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
Value of TASK_UNMAPPED_SIZE on 2.4
All, TASK_UNMAPPED_SIZE is defined in include/asm-i386/processor.h as: #define TASK_UNMAPPED_SIZE(TASK_SIZE / 3) The value of TASK_SIZE is defined as PAGE_OFFSET which is set to 0xC000 (page.h). This works out to be a value of 0x400. The question is: Are there any negative side effects in defining TASK_UNMAPPED_SIZE to 0x100? By doing this we allow a process to access more memory. On Oracle it allows us to grow our buffer size from 1.7 GB to 2.4 GB improving overall performance by reducing I/O. Thanks in advance, -- === Josue Emmanuel Amaro [EMAIL PROTECTED] Linux Products Manager Phone: 650.506.1239 Intel and Linux Technologies Group Fax: 650.413.0167 === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-413-0167 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Intel and Linux Technologies version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Manager - Linux adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
Re: Value of TASK_UNMAPPED_SIZE on 2.4
Andrea, We will give it a try. How difficult would it be to move that patch to 2.4? It would be great if it could be a kernel configuration time option. Regards, Andrea Arcangeli wrote: > On Fri, Nov 03, 2000 at 09:27:07PM +0100, Kai Harrekilde-Petersen wrote: > > Is this available as a patch, or preferably as a compilation option to > > They're available here: > > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-mapping-1.bz2 > >ftp://ftp.us.kernel.org/pub/linux/kernel/people/andrea/patches/v2.2/2.2.14/bigmem-large-task-1.bz2 > > But they're against 2.2.x + bigmem. The first one is still valid (and it's > similar to the one discussed here). The second one doesn't apply to 2.4.x > and both vmlinux.lds and PAGE_OFFSET should be changed that way to > make it to work there. > > Andrea > - > 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/ -- === Josue Emmanuel Amaro [EMAIL PROTECTED] Linux Products Manager Phone: 650.506.1239 Intel and Linux Technologies Group Fax: 650.413.0167 === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-413-0167 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Intel and Linux Technologies version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Manager - Linux adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
Re: Value of TASK_UNMAPPED_SIZE on 2.4
All, Additional follow up. The idea of modifying this variable is to increase the amount of memory that a process can use. A database like Oracle can benefit from this because it allows Oracle to create a bigger data buffer. An obvious side effect of allocating more physical memory to a process is that there is less available for other things like the kernel buffer cache. This brings up a question. Would a write of a data block from the Oracle data buffer incur a "read penalty" if the block is not in the buffer cache? For example, a data block is read by Oracle into its buffer. Since it is read through the file system, this block is now present in the buffer cache too. After a while, and since we have allocated most of the memory to Oracle, that block is removed/replaced from the cache. Now a transaction modifies that block in Oracle's buffer and Oracle writes it to disk. Does the kernel firsts reads that block into the buffer cache, "read penalty", and then writes it to disk? Or does it just write through the buffer cache now placing the block in the kernel buffer cache? Regards, -- ======= Josue Emmanuel Amaro [EMAIL PROTECTED] Linux Products Manager Phone: 650.506.1239 Intel and Linux Technologies Group Fax: 650.413.0167 === begin:vcard n:Amaro;Josue Emmanuel tel;cell:650-245-5131 tel;fax:650-413-0167 tel;work:650-506-1239 x-mozilla-html:FALSE url:http://www.oracle.com org:Intel and Linux Technologies version:2.1 email;internet:[EMAIL PROTECTED] title:Sr.Product Manager - Linux adr;quoted-printable:;;500 Oracle Parkway=0D=0AMS1ip4;Redwood Shores;CA;94065;United States fn:Josue Emmanuel Amaro end:vcard
