Re: [PATCH] sparc64: boot performance improvements
On Tue, Oct 6, 2015 at 8:39 PM, Eric Snowberg wrote:
> Keep of devices open. This can save 6 - 7 seconds per open call and
> can decrease boot times from over 10 minutes to 29 seconds on
> larger SPARC systems. The open/close calls with some vendors'
> SAS controllers cause the entire card to be reinitialized after
> each close.
>
Is it necessary to close these handles before launching kernel? It
sounds like it can accumulate quite a lot of them - are there any
memory limits/restrictions? Also your patch is rather generic and so
applies to any IEEE1275 platform, I think some of them may have less
resources. Just trying to understand what run-time cost is.
> Signed-off-by: Eric Snowberg
> ---
> grub-core/kern/ieee1275/ieee1275.c | 39
>
> 1 files changed, 39 insertions(+), 0 deletions(-)
>
> diff --git a/grub-core/kern/ieee1275/ieee1275.c
> b/grub-core/kern/ieee1275/ieee1275.c
> index 9821702..30f973b 100644
> --- a/grub-core/kern/ieee1275/ieee1275.c
> +++ b/grub-core/kern/ieee1275/ieee1275.c
> @@ -19,11 +19,24 @@
>
> #include
> #include
> +#include
> +#include
> +#include
>
> #define IEEE1275_PHANDLE_INVALID ((grub_ieee1275_cell_t) -1)
> #define IEEE1275_IHANDLE_INVALID ((grub_ieee1275_cell_t) 0)
> #define IEEE1275_CELL_INVALID ((grub_ieee1275_cell_t) -1)
>
> +struct grub_of_opened_device
> +{
> + struct grub_of_opened_device *next;
> + struct grub_of_opened_device **prev;
> + grub_ieee1275_ihandle_t ihandle;
> + char *path;
> +};
> +
> +static struct grub_of_opened_device *grub_of_opened_devices;
> +
>
>
> int
> @@ -452,6 +465,18 @@ grub_ieee1275_open (const char *path,
> grub_ieee1275_ihandle_t *result)
>}
>args;
>
> + struct grub_of_opened_device *dev;
> +
> + FOR_LIST_ELEMENTS(dev, grub_of_opened_devices)
> +if (grub_strcmp(dev->path, path) == 0)
> + break;
> +
> + if (dev)
> + {
> +*result = dev->ihandle;
> +return 0;
> + }
> +
>INIT_IEEE1275_COMMON (&args.common, "open", 1, 1);
>args.path = (grub_ieee1275_cell_t) path;
>
> @@ -460,6 +485,11 @@ grub_ieee1275_open (const char *path,
> grub_ieee1275_ihandle_t *result)
>*result = args.result;
>if (args.result == IEEE1275_IHANDLE_INVALID)
> return -1;
> +
> + dev = grub_zalloc(sizeof(struct grub_of_opened_device));
Error check
> + dev->path = grub_strdup(path);
Ditto
> + dev->ihandle = args.result;
> + grub_list_push(GRUB_AS_LIST_P (&grub_of_opened_devices), GRUB_AS_LIST
> (dev));
>return 0;
> }
>
> @@ -473,6 +503,15 @@ grub_ieee1275_close (grub_ieee1275_ihandle_t ihandle)
>}
>args;
>
> + struct grub_of_opened_device *dev;
> +
> + FOR_LIST_ELEMENTS(dev, grub_of_opened_devices)
> +if (dev->ihandle == ihandle)
> + break;
> +
> + if (dev)
> +return 0;
> +
How can we come here (i.e. can we get open handle without grub_ieee1275_open)?
>INIT_IEEE1275_COMMON (&args.common, "close", 1, 0);
>args.ihandle = ihandle;
>
> --
> 1.7.1
>
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: cpuid -p
On Wed, Oct 7, 2015 at 1:00 AM, Ben Hildred <426...@gmail.com> wrote: > The most recent documentation on the cpuid call says that it only supports > the -l option. I have a use case for detecting pae. Has anyone else had need > for detecting pae? is the -p option the best option for pae detection (new > code needed)? Do we want to maintain the current behavior for no options? > Current GIT supports "cpuid -p", it is just missing in help output/documentation. Patches are welcome. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V2] ofnet: Do not set SUFFIX for sun4v network devices
Hi!
On 09/07/2015 02:13 PM, Stanislav Kholmanskikh wrote:
sun4v vnet devices do not implement the support of duplex and speed
instance attributes. An attempt to open such a device with
the attributes will fail:
ok select net:speed=auto,duplex=auto
Unknown key 'speed'
Unknown key 'duplex'
Manual Configuration: Host IP, boot server and filename must be specified
WARNING: /virtual-devices@100/channel-devices@200/network@0: Can't open OBP
standard TFTP package
Can't open device
ok
Therefore, let's not set SUFFIX for such devices.
Signed-off-by: Stanislav Kholmanskikh
---
Changes since V1:
* handle "compatible" property as an array of strings
Could anybody look at it, please?
Thanks.
grub-core/net/drivers/ieee1275/ofnet.c | 41 ++-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/grub-core/net/drivers/ieee1275/ofnet.c
b/grub-core/net/drivers/ieee1275/ofnet.c
index eea8e71..13970bd 100644
--- a/grub-core/net/drivers/ieee1275/ofnet.c
+++ b/grub-core/net/drivers/ieee1275/ofnet.c
@@ -305,6 +305,7 @@ search_net_devices (struct grub_ieee1275_devalias *alias)
grub_uint64_t prop;
grub_uint8_t *pprop;
char *shortname;
+ char need_suffix = 1;
if (grub_strcmp (alias->type, "network") != 0)
return 0;
@@ -325,7 +326,43 @@ search_net_devices (struct grub_ieee1275_devalias *alias)
#define SUFFIX
":speed=auto,duplex=auto,1.1.1.1,dummy,1.1.1.1,1.1.1.1,5,5,1.1.1.1,512"
- if (!grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+ if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+need_suffix = 0;
+
+ /* sun4v vnet devices do not support setting duplex/speed */
+ {
+char *ptr;
+
+grub_ieee1275_finddevice (alias->path, &devhandle);
+
+grub_ieee1275_get_property_length (devhandle, "compatible", &prop_size);
+if (prop_size > 0)
+ {
+ pprop = grub_malloc (prop_size);
+ if (!pprop)
+ {
+ grub_free (card);
+ grub_free (ofdata);
+ grub_print_error ();
+ return 1;
+ }
+
+ if (!grub_ieee1275_get_property (devhandle, "compatible",
+pprop, prop_size, NULL))
+ {
+ for (ptr = (char *) pprop; ptr - (char *) pprop < prop_size;
+ptr += grub_strlen (ptr) + 1)
+ {
+ if (!grub_strcmp(ptr, "SUNW,sun4v-network"))
+ need_suffix = 0;
+ }
+ }
+
+ grub_free (pprop);
+ }
+ }
+
+ if (need_suffix)
ofdata->path = grub_malloc (grub_strlen (alias->path) + sizeof (SUFFIX));
else
ofdata->path = grub_malloc (grub_strlen (alias->path) + 1);
@@ -335,7 +372,7 @@ search_net_devices (struct grub_ieee1275_devalias *alias)
return 0;
}
ofdata->suffix = grub_stpcpy (ofdata->path, alias->path);
- if (!grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+ if (need_suffix)
grub_memcpy (ofdata->suffix, SUFFIX, sizeof (SUFFIX));
else
*ofdata->suffix = '\0';
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] sparc64 - use correct drive name within grub_util_sparc_setup
06.10.2015 20:21, Eric Snowberg пишет: Incorrect drive name was being passed into grub_util_sparc_setup, causing the grub-install to fail. Signed-off-by: Eric Snowberg --- util/grub-install.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/util/grub-install.c b/util/grub-install.c index df5c7e5..eabd6de 100644 --- a/util/grub-install.c +++ b/util/grub-install.c @@ -1698,7 +1698,7 @@ main (int argc, char *argv[]) /* Now perform the installation. */ if (install_bootsector) grub_util_sparc_setup (platdir, "boot.img", "core.img", -install_device, force, +install_drive, force, fs_probe, allow_floppy, 0 /* unused */ ); break; Applied. Thanks! ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH V2] ofnet: Do not set SUFFIX for sun4v network devices
07.10.2015 17:52, Stanislav Kholmanskikh пишет:
Hi!
On 09/07/2015 02:13 PM, Stanislav Kholmanskikh wrote:
sun4v vnet devices do not implement the support of duplex and speed
instance attributes. An attempt to open such a device with
the attributes will fail:
ok select net:speed=auto,duplex=auto
Unknown key 'speed'
Unknown key 'duplex'
Manual Configuration: Host IP, boot server and filename must be specified
WARNING: /virtual-devices@100/channel-devices@200/network@0: Can't
open OBP standard TFTP package
Can't open device
ok
Therefore, let's not set SUFFIX for such devices.
Signed-off-by: Stanislav Kholmanskikh
---
Changes since V1:
* handle "compatible" property as an array of strings
Could anybody look at it, please?
I was hoping you lost patience and fixed FCODE :)
Sorry for delay, applied.
Thanks.
grub-core/net/drivers/ieee1275/ofnet.c | 41
++-
1 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/grub-core/net/drivers/ieee1275/ofnet.c
b/grub-core/net/drivers/ieee1275/ofnet.c
index eea8e71..13970bd 100644
--- a/grub-core/net/drivers/ieee1275/ofnet.c
+++ b/grub-core/net/drivers/ieee1275/ofnet.c
@@ -305,6 +305,7 @@ search_net_devices (struct grub_ieee1275_devalias
*alias)
grub_uint64_t prop;
grub_uint8_t *pprop;
char *shortname;
+ char need_suffix = 1;
if (grub_strcmp (alias->type, "network") != 0)
return 0;
@@ -325,7 +326,43 @@ search_net_devices (struct grub_ieee1275_devalias
*alias)
#define SUFFIX
":speed=auto,duplex=auto,1.1.1.1,dummy,1.1.1.1,1.1.1.1,5,5,1.1.1.1,512"
- if (!grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+ if (grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+need_suffix = 0;
+
+ /* sun4v vnet devices do not support setting duplex/speed */
+ {
+char *ptr;
+
+grub_ieee1275_finddevice (alias->path, &devhandle);
+
+grub_ieee1275_get_property_length (devhandle, "compatible",
&prop_size);
+if (prop_size > 0)
+ {
+pprop = grub_malloc (prop_size);
+if (!pprop)
+ {
+grub_free (card);
+grub_free (ofdata);
+grub_print_error ();
+return 1;
+ }
+
+if (!grub_ieee1275_get_property (devhandle, "compatible",
+ pprop, prop_size, NULL))
+ {
+for (ptr = (char *) pprop; ptr - (char *) pprop < prop_size;
+ ptr += grub_strlen (ptr) + 1)
+ {
+if (!grub_strcmp(ptr, "SUNW,sun4v-network"))
+ need_suffix = 0;
+ }
+}
+
+grub_free (pprop);
+ }
+ }
+
+ if (need_suffix)
ofdata->path = grub_malloc (grub_strlen (alias->path) + sizeof
(SUFFIX));
else
ofdata->path = grub_malloc (grub_strlen (alias->path) + 1);
@@ -335,7 +372,7 @@ search_net_devices (struct grub_ieee1275_devalias
*alias)
return 0;
}
ofdata->suffix = grub_stpcpy (ofdata->path, alias->path);
- if (!grub_ieee1275_test_flag (GRUB_IEEE1275_FLAG_NO_OFNET_SUFFIX))
+ if (need_suffix)
grub_memcpy (ofdata->suffix, SUFFIX, sizeof (SUFFIX));
else
*ofdata->suffix = '\0';
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Can we prefix this list?
Can you guys prefix the subject line of this list like other lists do? Would make managing/filtering this list into folders much easier. Example Subject: [grub-devel] Can we prefix this list? -- Shaun Reitan Network Data Center Host, Inc. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: Can we prefix this list?
07.10.2015 20:03, Shaun Reitan пишет: Can you guys prefix the subject line of this list like other lists do? Would make managing/filtering this list into folders much easier. I do not have any problems filtering it into folders now. Example Subject: [grub-devel] Can we prefix this list? -- Shaun Reitan Network Data Center Host, Inc. ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
GNU GRUB maintenance
Hello, all. I'm sorry for not being available to do enough maintenance for GRUB in last time but I was overbooked. Yet there is a good news. At Google there is a 20% project and GRUB has been approved as 20% project for me. The goal is to have 2.02 released before the end of this year. Other than the raw lack of time there is another issue which makes maintenance difficult: inefficient VCS. It requires me or someone with privileges manually copy the patch. What other systems would be ok? It obviously has to be a free software and hosted on free software-friendly hosting. It also has to have an efficient 1-click merge (so that someone with privileges can get any patch submitted to the system merged in couple of clicks). signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GNU GRUB maintenance
On Wednesday, October 7, 2015, Vladimir 'φ-coder/phcoder' Serbinenko < phco...@gmail.com> wrote: > Hello, all. I'm sorry for not being available to do enough maintenance > for GRUB in last time but I was overbooked. Yet there is a good news. At > Google there is a 20% project and GRUB has been approved as 20% project > for me. The goal is to have 2.02 released before the end of this year. > Other than the raw lack of time there is another issue which makes > maintenance difficult: inefficient VCS. It requires me or someone with > privileges manually copy the patch. What other systems would be ok? It > obviously has to be a free software and hosted on free software-friendly > hosting. It also has to have an efficient 1-click merge (so that someone > with privileges can get any patch submitted to the system merged in > couple of clicks). I know that git is pretty popular... ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GNU GRUB maintenance
On 07.10.2015 23:36, SevenBits wrote: > > > On Wednesday, October 7, 2015, Vladimir 'φ-coder/phcoder' Serbinenko > mailto:phco...@gmail.com>> wrote: > > Hello, all. I'm sorry for not being available to do enough maintenance > for GRUB in last time but I was overbooked. Yet there is a good news. At > Google there is a 20% project and GRUB has been approved as 20% project > for me. The goal is to have 2.02 released before the end of this year. > Other than the raw lack of time there is another issue which makes > maintenance difficult: inefficient VCS. It requires me or someone with > privileges manually copy the patch. What other systems would be ok? It > obviously has to be a free software and hosted on free software-friendly > hosting. It also has to have an efficient 1-click merge (so that someone > with privileges can get any patch submitted to the system merged in > couple of clicks). > > > > I know that git is pretty popular... > Git integration is a plus. Like gerrit: git based with a review system on top of it. > > ___ > Grub-devel mailing list > Grub-devel@gnu.org > https://lists.gnu.org/mailman/listinfo/grub-devel > signature.asc Description: OpenPGP digital signature ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: [PATCH] sparc64: boot performance improvements
> On Oct 7, 2015, at 2:36 AM, Andrei Borzenkov wrote:
>
> On Tue, Oct 6, 2015 at 8:39 PM, Eric Snowberg
> wrote:
>> Keep of devices open. This can save 6 - 7 seconds per open call and
>> can decrease boot times from over 10 minutes to 29 seconds on
>> larger SPARC systems. The open/close calls with some vendors'
>> SAS controllers cause the entire card to be reinitialized after
>> each close.
>>
>
> Is it necessary to close these handles before launching kernel?
On SPARC hardware it is not necessary. I would be interested to hear if it is
necessary on other IEEE1275 platforms.
> It sounds like it can accumulate quite a lot of them - are there any
> memory limits/restrictions? Also your patch is rather generic and so
> applies to any IEEE1275 platform, I think some of them may have less
> resources. Just trying to understand what run-time cost is.
The most I have seen are two entries in the linked list. So the additional
memory requirements are very small. I have tried this on a T2000, T4, and T5.
The path name sent into the grub_ieee1275_open function is not consistent
throughout the code, even though it is referencing the same device. Originally
I tried having a global containing the path sent into grub_ieee1275_open, but
this failed due to the various ways of referencing the same device name. That
is why I added the linked list just to be safe. Caching the
grub_ieee1275_ihandle_t this way saves a significant amount of time, since OF
calls are expensive. We were seeing the same device opened 50+ times in the
process of displaying the grub menu and then launching the kernel.
>
>> Signed-off-by: Eric Snowberg
>> ---
>> grub-core/kern/ieee1275/ieee1275.c | 39
>>
>> 1 files changed, 39 insertions(+), 0 deletions(-)
>>
>> diff --git a/grub-core/kern/ieee1275/ieee1275.c
>> b/grub-core/kern/ieee1275/ieee1275.c
>> index 9821702..30f973b 100644
>> --- a/grub-core/kern/ieee1275/ieee1275.c
>> +++ b/grub-core/kern/ieee1275/ieee1275.c
>> @@ -19,11 +19,24 @@
>>
>> #include
>> #include
>> +#include
>> +#include
>> +#include
>>
>> #define IEEE1275_PHANDLE_INVALID ((grub_ieee1275_cell_t) -1)
>> #define IEEE1275_IHANDLE_INVALID ((grub_ieee1275_cell_t) 0)
>> #define IEEE1275_CELL_INVALID ((grub_ieee1275_cell_t) -1)
>>
>> +struct grub_of_opened_device
>> +{
>> + struct grub_of_opened_device *next;
>> + struct grub_of_opened_device **prev;
>> + grub_ieee1275_ihandle_t ihandle;
>> + char *path;
>> +};
>> +
>> +static struct grub_of_opened_device *grub_of_opened_devices;
>> +
>>
>>
>> int
>> @@ -452,6 +465,18 @@ grub_ieee1275_open (const char *path,
>> grub_ieee1275_ihandle_t *result)
>> }
>> args;
>>
>> + struct grub_of_opened_device *dev;
>> +
>> + FOR_LIST_ELEMENTS(dev, grub_of_opened_devices)
>> +if (grub_strcmp(dev->path, path) == 0)
>> + break;
>> +
>> + if (dev)
>> + {
>> +*result = dev->ihandle;
>> +return 0;
>> + }
>> +
>> INIT_IEEE1275_COMMON (&args.common, "open", 1, 1);
>> args.path = (grub_ieee1275_cell_t) path;
>>
>> @@ -460,6 +485,11 @@ grub_ieee1275_open (const char *path,
>> grub_ieee1275_ihandle_t *result)
>> *result = args.result;
>> if (args.result == IEEE1275_IHANDLE_INVALID)
>> return -1;
>> +
>> + dev = grub_zalloc(sizeof(struct grub_of_opened_device));
>
> Error check
I’ll resubmit V2 with this change
>> + dev->path = grub_strdup(path);
>
> Ditto
>
I’ll resubmit V2 with this change
>> + dev->ihandle = args.result;
>> + grub_list_push(GRUB_AS_LIST_P (&grub_of_opened_devices), GRUB_AS_LIST
>> (dev));
>> return 0;
>> }
>>
>> @@ -473,6 +503,15 @@ grub_ieee1275_close (grub_ieee1275_ihandle_t ihandle)
>> }
>> args;
>>
>> + struct grub_of_opened_device *dev;
>> +
>> + FOR_LIST_ELEMENTS(dev, grub_of_opened_devices)
>> +if (dev->ihandle == ihandle)
>> + break;
>> +
>> + if (dev)
>> +return 0;
>> +
>
> How can we come here (i.e. can we get open handle without grub_ieee1275_open)?
>
I don’t see it being possible with SPARC and would assume other platforms could
not get there either. I’m not familiar with the other IEEE1275 platforms to
know if this would be appropriate, but If there isn’t a platform that needs
this close function, could the function be changed to do nothing but return 0?
>> INIT_IEEE1275_COMMON (&args.common, "close", 1, 0);
>> args.ihandle = ihandle;
>>
>> --
>> 1.7.1
>>
>>
>> ___
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: GNU GRUB maintenance
On Thu, Oct 8, 2015 at 6:02 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: > On 07.10.2015 23:36, SevenBits wrote: >> What other systems would be ok? It >> obviously has to be a free software and hosted on free software-friendly >> hosting. It also has to have an efficient 1-click merge (so that someone >> with privileges can get any patch submitted to the system merged in >> couple of clicks). >> >> >> >> I know that git is pretty popular... >> > Git integration is a plus. Like gerrit: git based with a review system > on top of it. Is "has to be a free software" an absolute requirement? Github, the web, is not open source. However it uses git, adds features (like the "1-click merge" and organization), and free (to use) for open source projects. Some open source projects hosted on github (and use the organization feature): https://github.com/zfsonlinux https://github.com/freeradius Some open source projects using github as mirror: https://help.github.com/articles/about-github-mirrors/ Github help on web-based pull request: https://help.github.com/articles/using-pull-requests/ https://help.github.com/articles/merging-a-pull-request/ The downside with github that I can think of, is that for efficient use of the "1-click merge" web interface, the pull request must be created from the github interface (and the discussion will happen there as well), as opposed to in the mailing list like what currently happen. Then again, if the intention is simply to provide "notification to the mailing list" (and no need to allow discussion participation FROM the mailing list on the pull requests), you could probably work around that by having a normal git account with mailing-list address "watching" your repository. -- Fajar ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
